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Abstract 


This  report  consists  of  three  papers,  prepared  for  separate 
presentation  at  conferences,  that  have  a  common  thread:  they  discuss 
techniques  that  can  be  expected  to  improve  the  reliability  of  software. 

The  first  surveys  language  design  principles,  and  presents  empirical 
evidence  that  even  small  language  changes  can  significantly  affect 
reliability.  The  other  two  are  more  theoretical  and  discuss  specification 
techniques  for  programs  and  programming  languages,  respecti vely. 
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0 .  Abstract 

The  language  in  which  programs  are  written  can  have  a 
substantial  effect  on  their  reliability.  This  paper 
discusses  the  design  of  programming  languages  to  enhance 
reliability.  It  presents  several  general  design  principles, 
and  then  applies  them  to  particular  language  constructs. 
Since  we  can  not  logically  prove  the  validity  of  such  design 
principles,  empirical  evidence  is  needed  to  support  or 
discredit  them.  Gannon  has  performed  a  major  experiment  to 
measure  the  effect  of  nine  specific  language  design 
decisions  in  one  context.  Analysis  of  the  frequency  and 
persistence  of  errors  shows  that  several  decisions  had  a 
significant  impact  on  reliability. 
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1*  Introduction 


One  approach  to  the  attainment  of  reliable  software  is 
the  development  of  programs  that  have  a  very  high 
probability  of  being  correct*  This  probability  can  be 
increased  in  two  ways:  by  reducing  the  probability  of 
programming  errors*  and  by  increasing  the  probability  of 
detecting  any  errors  that  are  made*  Appropriate  language 
design  can  contribute  to  both  of  these  goals. 

This  paper  is  concerned  with  a  single  aspect  of  language 
design:  increasing  the  reliability  of  programs  written  in 
the  language.  It  discusses  both  general  and  specific  ways 
of  improving  reliability*  and  presents  empirical  evidence 
about  the  extent  to  which  a  number  of  language  features 
actually  affect  program  reliability.  Any  real  language  must 
strike  a  balance  among  a  number  of  goals  (simplicity*  power* 
generality*  elegance*  machine- independence*  efficiency* 
etc.).  Taking  reliability  explicitly  into  account  does  not 
seem  to  require  major  sacrifices  of  the  other  goals*  and  we 
will  present  evidence  that  very  small  changes  in  a  language 
can  result  in  significant  improvements  in  program 
reliability. 

Section  2  discusses  ways  in  which  a  programming  language 
can  increase  the  confidence  of  its  users  in  the  software 
that  they  -produce.  Section  3  surveys  particular  language 
features  that  contribute  to  reliability*  in  the  categories 
of  disciplined  structures*  explicit  interfaces*  redundancy, 
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display  of  program  text,  and  association  of  test  cases  with 
modules.  Section  4  outlines  observations  and  experiments 
that  have  been  used  to  obtain  empirical  evidence  about  the 
programming  process.  Section  5  describes  a  new  experiment, 
in  which  a  number  of  orthogonal  features  in  an  existing 
language  were  redesigned  to  produce  a  new  dialect  of  the 
language.  To  gather  data  with  which  to  evaluate  the  altered 
features,  two  groups  of  programmers,  one  working  in  each 
language,  were  observed.  Section  6  discusses  the  types  and 
frequencies  of  errors  attributable  to  each  language  feature. 

2.  General  considerations 

Programming  languages  should  lead  to  confidence  in  the 
correctness  of  programs.  They  should  aid  the  programmer  not 
only  in  the  coding  process,  but  also  in  the  processes  of 
(formally  or  informally)  proving  programs  correct  and  of 
maintaining  programs. 

Ultimately,  our  most  powerful  weapon  against  incorrect 
programs  lies  in  the  understanding  of  those  who  write  and 
check  them.  Programmers  must  master  their  languages  for  the 
purposes  of  both  writing  and  reading  programs.  Two 
attributes  of  a  language  play  major  roles  in  a  programmer's 
ability  to  master  the  language:  its  size  and  its 
naturalness.  A  language  should  contain  constructs  that 
encourage  the  clearest  possible  statement  of  the 
programmer's  intentions.  However,  the  need  for  more 
constructs  must  be  balanced  against  the  need  to  keep  the 
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language  simple  [Hoare  1973a],  [Wirth  1974].  The  importance 
of  high-level  languages  comes  at  least  as  much  from  the 
errors  and  "cleverness”  that  they  prevent  as  from  the 
powerful  operations  that  they  make  convenient  [Wirth  1971a]. 

If  we  are  to  have  confidence  in  the  correctness  of 
programs,  then  our  language  must  never  surprise  us  in  any  of 
its  effects.  The  meaning  of  features  in  a  language  should 
be  precise,  and  correspond  to  a  sense  of  "rightness"  based 
upon  our  experiences  with  natural  languages,  mathematics, 
and  other  programming  languages  [Weinberg  1971].  We  should 
aim  for  a  language  in  which  programmers  will  quickly  become 
fluent,  without  continual  reference  to  manuals  or  the  need 
to  run  experimental  programs. 

Our  language  should  contain  features  that  allow 
violations  of  a  programmer’s  intentions  to  be  detected  as 
errors.  Furthermore,  this  detection  should  be  performed  as 
early  as  possible  (i.e.,  at  compile  time)  both  to  speed 

i 

program  development  and  to  free  the  programmer  from  complete 
dependence  on  running  a  sufficient  set  of  test  cases. 

We  may  also  raise  our  level  of  confidence  in  a  program 
by  proving  it  correct.  Hoare  has  suggested  that  formally 
defining  the  semantics  of  a  language  with  proof  rules  will 
suggest  methods  for  improving  the  language.  For  example, 
Hoare  has  found  a  number  of  restrictions  on  procedure 
invocations  that  facilitate  the  construction  of  proofs  using 
his  assertion  language  [Hoare  1971],  without  significantly 
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Constructs  that  lead  to 


reducing  expressive  power, 
difficult  proofs  are  less  likely  to  be  used  correctly  than 
constructs  that  yield  simple  proofs.  Unfortunately,  the 
simplicity  with  which  proof  rules  can  be  stated  does  not 
always  correlate  with  simplicity  of  proof  (e.g. ,  the  go  to 
[Clint  and  Hoare  1972]). 

Concern  with  reliability  can  not  stop  when  a  program  is 
"finished.®*  Large  systems  never  achieve  stability;  they 
continue  to  need  correction  and  to  grow.  In  this  process, 
system  structure  degeneration  and  personnel  turnover 
decrease  familiarity  with  the  system.  Ultimately,  the 
required  maintenance  effort  increases  rapidly  [Belady  and 
Lehman  1971].  The  rapid  increase  in  maintenance  effort  that 
appears  in  aging  systems  can  be  delayed  by  increased 
communication  between  the  programmers  implementing  a  system 
and  those  who  will  be  maintaining  it.  It  is  important  that 
the  language  make  this  communication  clear,  convenient,  and 
precise. 

3.  Specific  language  features 

3.  1  Disciplined  structures 

It  should  no  longer  be  necessary  to  debate  the 
desirability  of  undisciplined  structures  such  as  go  to 
[ Di jkstra  1968],  bit  (16)  [Clark  and  Horning  1973],  and 
pointer  [Hoare  1973b].  These  features  introduce  a 

substantial  barrier  to  the  systematic  communication  of  a 
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it  is  not  sufficient  to 


programmer's  intent.  However, 
merely  delete  these  structures  from  the  language.  They  must 
be  replaced  by  disciplined  constructs  that  are  both  clear 
and  efficient. 

3.2  Explicit  interfaces 

Large  systems  must  be  written  and  understood  as  sets  of 
interconnected  modules.  Generally,  mastering  the  modules 
separately  is  relatively  easy;  it  is  their  interactions  that 
become  unmanageable.  A.  programming  language  should  cater  to 
the  construction  of  hierarchies  of  modules,  and  the  explicit 
statement  and  enforcement  of  their  interfaces.  In  addition, 
if  each  module  is  to  be  small  (e.g.,  limited  to  one  page  of 
source  text) ,  then  efficiency  requires  that  module  linkage 
overhead  at  run  time  be  low. 

3.2.1  Hierarchies  of  procedures 

Many  languages  use  scope  rules  similar  to  those  of 
ALGOL  60  in  order  to  define  interfaces.  Wulf  and  Shaw 
[1973]  have  catalogued  the  deficiencies  of  this  mechanism. 
They  also  have  enumerated  some  desirable  attributes  of  an 
alternative  mechanism. 

1.  The  scope  of  a  name  should  not  automatically  be 
extended  to  inner  blocks. 

2.  The  right  to  access  a  name  should  be  granted  by 
mutual  agreement  between  creator  and  accessor. 
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3.  Access  rights  to  a  structure  and  to  its 
substructures  should  be  decoupled. 

4.  It  should  be  possible  to  distinguish  different  types 
of  access. 

5.  Data  definition*  name  access*  and  storage  allocation 
should  be  decoupled. 

Some  of  these  attributes  could  be  grafted  onto 
conventional  block  structure  in  the  following  manner: 
Programmers  must  explicitly  specify  the  access  rights  of 
each  inner  block  to  each  variable  and  procedure*  both  with 
the  item  whose  access  is  being  restricted*  and  with  the 
block  in  which  an  attempt  is  made  to  access  the  item.  For 
example*  a  variable  might  have  access  rights  that  permit 
instances  of  it  to  be  allocated  or  deallocated*  and  its 
value  to  be  read  and  written;  the  right  to  invoke  a 
procedure  might  also  be  explicitly  specified. 

3.2.2  Hierarchies  of  data 

Current  research  suggests  that  data  structures  provide  a 
basis  for  hierarchical  modularization  that  is  at  least  as 
important  as  (and  less  well-understood  than)  that  provided 
by  procedures.  SIMULA  67  classes  [Dahl  et  al.  1970]  are  the 
starting  point  for  several  new  language  designs 
incorporating  data  modules.  For  example*  a  cluster 
definition  in  CLU  [ Liskov  and  Zilles  1974]  contains  an 
interface  specification*  an  object  representation*  code  to 
create  objects*  and  operation  definitions.  The  interface 
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specifies  the  name  of  the  cluster,  parameters  required  to 
create  an  instance  of  the  cluster,  and  a  list  of  the 
operations  the  programmer  may  perform  on  objects  of  the  type 
the  cluster  implements.  Objects  of  the  type  implemented  by 
the  cluster  are  viewed  as  atomic  by  its  users.  The 
representation  of  the  object  (i.e.,  its  storage  structure) 
may  be  manipulated  only  in  the  operations  within  the 
cluster. 

Clusters  allow  programmers  to  write  programs  in  terms  of 
the  objects  and  structures  that  the  programmers  find  natural 
for  particular  problems.  They  also  collect  and  limit  the 
distribution  of  information  about  how  such  objects  and 
structures  are  represented,  making  the  resulting  programs 
easier  to  maintain  and  prove  correct.  The  proof  of  a 
program  is  divided  into  two  parts:  a  proof  that  the  cluster 
implements  the  type,  and  a  proof  that  the  program  using  the 
type  is  correct. 

3 . 3  Redundancy 

Much  of  the  readability  of  high  level  languages  comes 
from  conciseness  based  on  the  suppression  of  irrelevant 
detail  or  the  exploitation  of  context.  However,  a  certain 
amount  of  redundancy  is  needed  for  easy  readability.  More 
importantly,  all  error  detection  and  correction  is  based  on 
the  availability  of  redundant  information.  Although  coding 
theory  provides  a  formal  measure  of  redundancy  foe  finite- 
state  codes,  and  techniques  for  generating  error-correcting 
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codes,  these  do  not  seem  to  be  directly  applicable  to 
programming  languages,  primarily  because  programmers  can  not 
be  expected  to  reliably  provide  such  88 low -level5*  redundancy. 

Not  all  redundancy  contributes  to  error  detection.  Some 
forms  of  redundancy  invite  errors  by  requiring  that 
duplicate  information  be  provided.  For  example,  the 
external  attribute  in  PL/I  permits  separately  compiled 
procedures  to  share  variables.  However,  if  the  variables 
are  not  declared  identically  in  each  of  the  procedures,  an 
error  may  occur  at  run  time.  By  contrast,  the  mechanism  for 
separate  compilation  in  the  SUE  System  Language  [Clark  and 
Horning  1971 ]  requires  only  a  single  identifier  to  be 
duplicated  to  permit  sharing  of  variables  and  complete  type 
checking.  Any  form  of  redundancy  will  lengthen  the  program 
text,  thereby  increasing  the  opportunity  for  "clerical88 
errors.  Thus,  we  should  be  careful  to  only  introduce 
redundancy  that  leads  to  the  detection  of  more  errors  than 
it  causes. 

To  be  effective,  redundancy  must  cause  errors  to 
transform  valid  programs  into  detectably  invalid  programs, 
le  do  not  want  a  compiler  to  be  overly  "forgiving. 88  If  a 
programmer  writes  a  statement  that  does  not  accurately 
convey  his  intention,  it  is  better  to  warn  him  than  to 
interpret  the  statement  "reasonably"  as  another  statement 
with  different  semantics.  Examples  of  useful  redundancy 
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declarative 


exist  in  languages  with  type  checking, 
redundancy,  and  invariance  conditions  or  assertions. 

3.3.1  Type  checking 

The  type  attribute  in  declarations  is  an  effective  form 
of  redundancy,  since  the  context  of  each  appearance  of  a 
data  item  can  be  checked  against  its  declared  type.  Both 
”typeless”  languages  (e.g.,  BLISS  [Wulf  et  al.  1971]  and 
BCPL  [Richards  1969])  and  languages  with  automatic  type 
conversion  (e.g.,  PL/I  [PL/I  1970  ])  defeat  type  checking, 
while  languages  with  large  numbers  of  incompatible  types 
(e.g.,  Pascal  [Wirth  1971a]}  enhance  it. 

Pointers  cause  additional  problems  [Hoare  1973b],  [Wirth 
1974].  By  introducing  the  type  pointer  and  forbidding 
arithmetic  operations  on  objects  with  this  type,  high-level 
languages  have  avoided  some  errors  common  to  the  use  of 
pointers  in  assembly  languages.  However,  in  PL/I,  pointers 
may  be  used  to  access  objects  whose  types  are  unknown.  This 
problem  can  be  eliminated  by  requiring  that  pointers  be 
declared  with  the  type  of  data  they  reference,  as  is  done  in 
Pascal,  the  SUE  System  Language,  and  ALGOL  68  [van 
Wijngaarden  et  al.  1969]. 

3.3.2  Declarative  redundancy 

The  declaration  of  further  information  about  variables 
(e.g.  ,  indicating  that  they  are  restricted  to  a  subrange  of 
their  type  as  in  Pascal,  or  that  they  represent  values  with 
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certain  units  and  dimensions  [ Hoare  1973a]  may  permit  the 
easy  detection  of  what  would  otherwise  be  subtle  "logical" 
errors.  Such  information  also  provides  valuable 
documentation ,  and  may  enable  the  compiler  to  perform 
optimizations?  particularly  in  storage  allocation.  In 
general,  it  helps  to  explicitly  declare  information  that 
must  otherwise  be  inferred  by  examining  all  uses  of  a 
variable. 

A  language,  such  as  PL/I,  that  does  not  require 
declaration  of  variables  will  treat  the  occurrence  of  a 
misspelled  reference  as  a  contextual  declaration  of  a  new 
variable.  A  diagnostic  compiler  for  such  a  language  (e.g., 
PL/C  [Conway  and  Wilcox  1973])  may  produce  a  warning  at  run 
time  that  the  contextually  declared  variable  has  not  been 
initialized. 

A  language  with  reserved  words  and  mandatory  declaration 
of  identifiers  allows  the  detection  of  many  keypunching 
mistakes  at  compile  time  (particularly  if  programmers  use 
long,  dissimilar  names) .  Horgan  has  proposed  an  algorithm 
for  repairing  spelling  errors  involving  single  character 
errors  or  transposed  characters  [Morgan  1970].  He  claims 
that  eighty  per  cent  of  the  spelling  errors  made  in 
programming  are  correctable  by  this  algorithm. 

Useless  redundancy  can  be  reduced  by  the  declaration  of 
constants.  Banning  all  "mystery  numbers"  outside  of 
declarations  for  named  constants  can  lead  to  more  readable 


11 


programs.  All  expressions  containing  the  named  constant 
will  use  a  consistent  value.  Furthermore,  to  change  the 
value  of  a  constant  each  place  it  occurs  in  a  program,  only 
the  declaration  for  the  constant  need  be  altered. 

3.3.3  Assertions  and  invariance  relations 

A  programmer  can  also  supply  redundant  information  about 
his  program  by  making  assertions  or  stating  invariance 
relations.  A.ssertions  are  true  or  false  at  a  particular 
point  in  a  program,  while  invariance  relations  hold  over 
several  statements  of  a  program  (e.g.,  a  procedure).  Type 
declarations  may  be  viewed  as  simple  invariance  relations 
that  involve  only  single  variables. 

It  is  common  to  do  most  (if  not  all)  type  checking  at 
compile  time.  By  contrast,  most  compilers  that  support  the 
assertion  feature  (such  as  those  for  the  SUE  System  Language 
and  ALGOL  W  [ Satterthwait e  1972])  generate  code  to  evaluate 
and  test  assertions  at  run  time.  However,  program  verifiers 
can  check  at  (or  before)  compile  time  that  the  source 
statements  and  assertions  are  consistent,  with  the  aid  of  a 
mechanical  theorem  prover  [ Igarishi  et  al.  1973]. 

3 « 4  Program  text 

In  the  maintenance  process  in  particular,  it  is  vital 
that  the  text  of  a  program  exhibit  the  logical  structure 
that  guided  its  construction.  If  structured  programs  are 
built  according  to  some  programming  methodology  (e.g.. 


12 


stepwise  refinement  [Wirth  1971b],  modular  decomposition 
[Parnas  1972],  or  action  clusters  [Naur  1969]),  the  language 
should  not  only  support  this  process,  but  record  it,  so  that 
future  readers  of  the  program  can  follow  the  series  of 
decisions  that  led  to  the  program® s  final  form.  (Perhaps  a 
more  realistic  goal  is  to  record  the  series  of  decisions 
that  would  have  been  taken  had  no  mistakes  been  made  in  the 
construction  process,  although  documentation  of  corrected 
mistakes  can  also  be  educational.)  Procedures  and  clusters 
may  often  be  natural  units  for  program  construction. 
However,  unless  their  overhead  is  low,  there  may  be  some 
temptation  to  gain  efficiency  by  removing  them  from  the 
final  form  of  the  program.  Source- program  structure  and 
run-time  efficiency  can  be  combined  if  the  compiler  itself 
has  the  capability  of  expanding  selected  procedure  and 
cluster  bodies  ,vin  line”  at  points  of  invocation. 

Even  so  simple  a  matter  as  the  formatting  of  the  program 
text  on  the  page  can  have  a  profound  influence  on  the 
reader® s  ability  to  comprehend  it  readily.  Current 
empirical  studies  on  the  ” psychological  complexity”  of 
programs  are  seeking  to  quantify  this  effect  and  to 
objectively  differentiate  between  good  and  bad  paragraphing 
styles  [Weissman  1974].  It  seems  clear  that  difficulty  in 
paragraphing  is  a  symptom  of  more  basic  language  flaws 
[Gordon  1975].  Many  compilers  now  either  automatically 
paragraph  source  listings  or  check  for  consistency  between  a 
program's  indentation  and  its  syntactic  structure. 
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3.5  Test  cases 

Every  program  unit  should  have  a  set  of  test  cases 
permanently  associated  with  it,  for  original  validation,  and 
re-validation  after  every  change  [Poole  1973].  It  is 
perhaps  debatable  whether  we  should  incorporate  these  in  the 
language  (as  a  kind  of  generalized  assertion)  or  relegate 
them  to  a  support  system,  but  their  desirability  is  clear. 

4.  Gathering  empirical  evidence 

We  can  not  logically  prove  that  particular  language 
features  will  enhance  the  reliability  of  programs.  However, 
we  can  gather  empirical  evidence  that  tends  to  confirm  or 
refute  such  claims.  We  can  observe  programmers  at  work  and 
examine  the  programs  they  create.  Experiments  can  be 
designed  to  investigate  portions  of  the  programming  process, 
and  to  reduce  the  bulk  of  data  that  observation  yields. 
However,  experiments  also  have  drawbacks  [Weinberg  1971]. 
The  behavior  of  the  subjects  in  an  experiment  may  be  so 
constrained  that  effects  that  would  be  observed  under 
natural  working  conditions  never  appear. 

4.1  Observations 

Several  studies  have  observed  the  errors  committed 
during  the  programming  process  [Moulton  and  Muller  1967], 
[Nagy  and  Pennebaker  1971],  [Boies  and  Gould  1972  ],  [Ichbiah 
and  Rissen  1971],  and  [Youngs  1974].  The  last  two  studies 
yielded  the  most  detailed  results. 
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A  language  design  effort  of  Xchbiah  and  Rissen 
identified  some  typical  errors  related  to  particular 
constructs.  These  errors,  called  characteristic  errors,  are 
found  in  constructs  that  implicitly  involve  the  notion  of 
order,  deal  with  global  data,  or  rely  cn  information  known 
only  at  run  time. 

Youngs  studied  the  errors  made  in  programming  by 
observing  programmers  working  in  high-level  languages. 
Thirty  beginning  programmers  and  twelve  advanced  programmers 
each  coded  one  or  two  of  nine  problems.  Youngs  required  the 
participants  to  submit  both  run  logs  and  all  the  computer 
output  from  the  problems.  He  classified  each  error 
according  to  his  coding  scheme  and  estimated  the  number  of 
constructions  in  the  program  that  were  identical  to  the 
construction  containing  the  error.  Over  a  quarter  of  the 
1258  errors  examined  occurred  in  assignment  statements. 
Conditional  branches  contained  less  than  five  per  cent  of 
the  observed  errors,  but  were  five  times  more  likely  to 
contain  errors  than  other  statements. 

4 . 2  Experiments 

Rather  than  comparing  entire  languages,  Sime,  Green,  and 
Guest  advocate  devising  micro-languages  stressing  specific 
features  common  to  many  languages  [Sime  et  al.  1973].  They 
designed  two  languages,  each  of  which  contained  one  of  two 
conditional  constructs:  a  nestable  two-tailed  if  construct 
(with  no  conjunction  or  disjunction  operations)  similar  to 


15 


that  of  ALGOL  60,  and  a  branch-to-label  construct  (with 
forward  labels  only)  used  in  many  low-level  languages.  To 
compare  these  constructs,  18  subjects  without  previous 
programming  experience,  half  working  in  each  language,  were 
asked  to  solve  five  card  sorxing  problems  using  an 
interactive  system.  While  all  nine  subjects  using  the 
nestable  conditional  construct  completed  all  five  problems 
in  90  minutes,  only  five  subjects  using  the  branch-to-label 
construct  did  so.  Statistically  significant  results  were 
obtained  demonstrating  that  the  subjects  using  the  nestable 
conditional  construct  made  fewer  semantic  errors  and  spent 
less  time  arriving  at  solutions  than  did  subjects  using  the 
branch-to-label  construct.  The  former  group  had  difficulty 
solving  the  more  complex  problems,  probably  because  of 
increased  levels  of  nesting.  This  suggests  that  syntactic 
devices  (e.g.,  conjunction  and  disjunction  operations) 
should  be  used  to  reduce  the  necessity  of  nesting. 

Other  experimental  studies  have  been  conducted  by  [Gould 
and  Drongowski  1972],  [Gould  1973  ],  [Miller  1973  ],  [Miller 
1974  ],  and  [Weissman  1974  ]. 

5 .  Gannon1 s  e X£er imen t 

In  a  recent  experiment,  Gannon  has  measured  the  effects 
on  reliability  of  nine  particular  language  design  decisions. 
This  section  briefly  discusses  his  methods;  the  next,  some 
of  his  more  interesting  results.  Complete  descriptions  are 
contained  in  [Gannon  1975].  The  experiment  involved 
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observing  the  errors  made  by  reasonably  experienced 
programmers  (graduate  and  fourth  year  undergraduate 
students?  including  part-time  students  with  industrial 
experience)  using  two  languages  to  write  rather  small  (75- 
200  lines) ,  but  fairly  sophisticated?  programs*  The 
languages  had  equivalent  power?  and  differed  only  in  ways 
that  were  expected  to  affect  reliability.  None  of  the 
subjects  had  prior  experience  in  either  language* 

The  first  language  was  TGPPS?  a  small  language  with 
constructs  that  support  concurrency  [  Czarnik  et  al.  1973], 
Using  some  of  the  techniques  outlined  in  Section  3,  and 
examining  the  language  for  characteristic  errors?  a  number 
of  mutually  independent  features  were  redesigned  in  an 
attempt  to  reduce  the  number  of  errors  made  and/or  the 
severity  of  errors.  TOPPSII  [Gannon  1973]  contained  the 
redesigned  features?  but  was  otherwise  identical  to  TOPPS. 
A  new  compiler  was  constructed  and  a  new  manual  prepared. 
Student  programmers  were  divided  into  two  groups?  one 
working  in  each  language?  to  obtain  the  desired  empirical 
evidence. 

For  the  purposes  of  this  study?  a  language  was  judged  to 
enhance  the  reliability  of  software  if  the  errors  committed 
by  its  users  were  less  frequent  and  less  persistent.  In 
addition  to  this  overall  comparison?  the  frequency  and 
persistence  of  errors  attributable  to  each  redesigned 
feature  were  compared.  The  underlying  hypothesis  was  that 
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errors  that  persist  during  the  debugging  process  are  similar 
to,  and  more  numerous  than,  those  that  remain  in  completed 
programs. 

5 . 1  The  languages 

TOPPS  is  an  expression-oriented  language  designed  for 
teaching  students  the  concepts  of  asynchronous  processes  and 
interprocess  communication.  In  addition,  TOPPS  provides  the 
user  with  operators  for  assignment  and  numerical  and  logical 
computations.  Character  string  manipulations  are  performed 
with  built-in  functions.  Expression  evaluation  proceeds 
from  right  to  left  with  equal  precedence  among  the 
operators. 

Control  constructs  permit  sequencing,  selection,  and 
repetition.  Sequencing  is  indicated  by  separating 
consecutive  expressions  with  a  semicolon.  The  semicolon  is 
used  as  a  separator;  no  semicolon  may  be  placed  after  the 
final  expression  in  a  compound  expression.  Selection  is 
performed  with  a  two-tailed  if  expression,  and  repetition 
with  a  repeat  expression. 

Compound  expressions  in  procedure  bodies  and  selection 
expressions  must  be  bracketted  using  either  parentheses  or 
begin-end.  However,  if  declarations  are  to  precede  the 
compound  expression,  begin-end  must  be  used.  Standard 
ALGOL  60  scope  rules  are  used  for  declared  items. 


A  number  of  these  features  were  redesigned  and  included 
in  TOPPSII.  No  significant  changes  were  made  to  the 
features  that  provide  for  asynchronous  processes  and 
interprocess  communication*  TOPPSII  is  statement-oriented, 
rather  than  expression-oriented*  The  number  of  infix 
operators  in  TOPPS  was  reduced  in  the  new  language,  with 
assignment  becoming  a  statement  and  the  Boolean  operators 
being  replaced  by  relation-connecting  functions.  Expression 
evaluation  was  altered  to  proceed  from  left  to  right  with 
traditional  precedence  among  the  operators  (e.g.r 
multiplications  performed  before  additions) . 

As  in  TOPPS,  sequencing  is  indicated  with  the  semicolon. 
However,  the  semicolon  in  TOPPSII  is  a  terminator  rather 
than  a  separator,  appearing  at  the  end  of  each  statement. 
The  two-tailed  if  of  TOPPS  has  been  augmented  by  a  case 
statement  in  the  new  language.  Also,  a  for  statement  has 
been  added  to  TOPPSII  to  allow  the  programmer  to  specify  an 
action  that  should  be  repeated  for  each  member  of  an  array. 
An  example  of  the  use  of  the  for  statement  can  be  found  at 
the  end  of  this  section. 

Statement  lists  in  procedure  bodies,  selection 
statements,  and  for  statements  in  TOPPSII  are  bracketted  by 
the  appropriate  reserved  word  and  end.  The  inclusion  of 
declarations  before  statement  lists  forces  the  introduction 
of  bec[in-end  around  the  declarations  and  statements  only  in 
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selection  and  iteration  statements  (where  declarations  are 
not  normally  expected) . 

The  scope  rules  of  TOPPSII  are  similar  to,  but  simpler 
than,  those  described  in  Section  3.2.1.  In  each  nested 
procedure,  a  programmer  must  declare  which  (if  any)  of  the 
variables  accessible  in  the  immediately  enclosing  procedure 
are  to  be  accessible  in  the  inner  procedure. 

One  other  addition  was  made  in  TOPPSII.  Besides  the 
literal  constants  (e.g.,  4  and  ®A.BC»)  available  in  almost 
every  language,  TOPSSII  includes  the  ability  to  declare 
named  constants. 

The  differences  are  summarized  in  the  following  table. 
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TOPPS 


TOPPSII 


1.  expression  evaluation 
right  to  left  with 
equal  precedence  among 
operators 

2.  assignment  operator 

3.  logical  operators 
&  and  | 

4.  semicolon  as  separator 

5.  selection  statements: 
if 

6.  repetition  statements: 
repeat 

7.  brackets  used  to  close 
compound  expressions: 
end  and  parentheses 

8.  automatic  inheritance 
of  environment 

9.  constants:  literals 


expression  evaluation 
left  to  right  with 
"traditional"  operator 
precedence 

assignment  statement 

logical  functions 
all  and  any 

semicolon  as  terminator 

selection  statements: 
if  and  case 

repetition  statements: 
repeat  and  for  each 
(element  of  an  array) 

brackets  used  to  close 
compound  statements: 
end 

inheritance  of  environment 
only  upon  specific  request 

constants:  literals  and 
named  constants 
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The  following  two  programs  illustrate  some  of  the 
differences  between  the  two  languages  (e.g.,  scope  rules, 
iteration  statements,  semicolons,  etc.) .  The  programs  each 
multiply  the  arrays  Left  and  Right  by  "firing  up"  the 
appropriate  number  of  processes  to  compute  each  element  of 
the  array  Result. 

TOPPS 


begin 

variable  Lower_left,  Lower_right,  Upper_right; 
input (Lower  left.  Lower_right,  Opper_right)  ; 
begin 

array  Left  bound  Lower_left-1 ,Lower_right-1 ; 
array  Right  bound  Lower_right- 1 ,Upper_right-1 ; 
array  Result  bound  Lower_left- 1 ,Upper_ right- 1 ; 
consumable  Are_you_f inished ; 
variable  I , J ; 

program  Multiply  of  Row,  Column 
producing  I_am__f inished  is 
begin 

variable  I; 

I  :  =~0 ; 

Result (Row, Column)  :=  0; 
repeat 

Result  (Row, Column)  :  = 

Result (Row, Column)  + 

Left  (Row, I)  *Right (I, Column) 
until  (I:=I«-1)  =  Lower_right; 
release  (I_am_f inished) 
end; 

input  (Left,  Right) ; 

I  :=”j  :=  0; 

/*  fire  up  Lower_lef t *Upper_right  processes  */ 
repeat 

repeat 

process  Multiply  of  I,J 

producing  Are _you_f inished 
until  (J  :=  J  +  if  =  Upper_right; 

J  :=  0 

until  (I: =  I  ♦  1)  =  Lower^left; 

/*  wait  fcr  all  processes  to  finish  */ 

I  :=  Lower_left.  *  Upper_right; 
repeat 

reguest (Are  you  finished) 
until"  (I  :=  I  -  1)  =0; 
output (Result) 
end 
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TOPPSII 


begin ; 

variable  Lower_left,  Lower_right,  Upper_right ; 
input  (Low er_l eft,  Lower_right,  Upper_right)  ; 
begin ; 

array  Left  bound  Lower_left~ 1 , Lower_right-1 ; 
arra^  Right  bound  Lower__right-1 , Upper_right- 1 ; 
array  Result  bound  Lower_left- 1 ,Upper_right-1 ; 
consumable  Ax e__yo unfinished ; 
variable  I , J ; 

parallel  procedure  Multiply  of  Row, Column 
producing  X_a  unfinished 
knows  Left  ,  Right ,  Result  ,Lower_right; 
variable  I; 

l”:=”o7” 

Result  (Row, Column)  : -  0; 
repeat ; 

Result (Row, Column)  := 

Result (Row, Column)  ♦ 

Left  (Row,  I)  *Right  (X , Column)  ; 

I  ®  =  I  -s-  1 ; 

until  I  -  Lower_right; 
release  (I_am_f inished)  ; 
end; 

input  (Left,  Right); 

I 

J  :=  0; 

/*  fire  up  Lower_le£t*Upper_right  processes  */ 
repeat : 

repeat ; 

process  Multiply  of  I, J 

producing  Are __you__f inished  ; 

J  :=  7; 

until  J  =  Upper^right; 

J 

I  ;=  I  ♦  1  ; 

until  I  =  Lower_left; 

/*  wait  for  all  processes  to  finish  */ 
for  each  I  of  Result; 

request (Are  y ou  finished)  ; 
end ; 

output (Result) ; 
end; 

end; 
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5 . 2  Observing  the  programming  process 


Initially,  51  programmers  were  divided  into  four  groups, 
based  on  whether  they  were  full-time  or  part-time  students 
and  undergraduate  or  graduate  students.  Within  each  group, 
subjects  were  randomly  assigned  to  work  in  one  of  the 
languages.  Later,  a  questionnaire  was  distributed  to 
determine  each  subject* s  programming  experience. 

Each  student  was  given  the  appropriate  language  manual 
and  similar  sample  programs  in  each  language  were  made 
available  for  examination  by  the  students.  To  reduce  bias 
introduced  by  the  experimenter,  no  tutorials  on  either 
language  were  offered.  (However,  questions  about  the 
languages  were  answered.) 

Each  student  was  required  to  program  the  same  two 
exercises  (approximate  length  75-200  lines)  and  asked  to 
submit  all  of  his  listings,  with  a  description  of  the  errors 
contained  in  each.  As  a  safeguard  against  uncooperative 
subjects,  a  copy  of  each  program  submitted  for  compilation 
was  made  automatically.  Students  were  required  to  include 
an  initial  comment  card  containing  information  for 
identification  (e.g.,  programmer  name,  program  name,  run 
number) • 

5 . 3  Evaluation  of  results 

The  listings  of  those  subjects  who  completed  both 
problems  were  examined  by  the  experimenter  for  errors.  A 
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detected  error  was  indicated  by  the  appearance  of  a 
diagnostic  message  or  an  incorrect  program  output, 
(Obviously,  it  is  a  matter  of  opinion  whether  or  not 
incorrect  program  output  is  sufficient  for  the  programmer  to 
detect  the  error.)  Undetected  errors  fall  in  two 
categories:  errors  that  a  subject  discovered  by  desk¬ 
checking  without  the  help  of  either  diagnostic  messages  or 
incorrect  program  output,  and  errors  detected  by  the 
experimenter  during  his  examination  of  (submitted)  solutions 
to  the  two  problems. 

In  runs  following  the  run  in  which  an  error  appeared, 
the  student  may  have  changed  his  program,  either  correcting 
the  error  or  altering  the  manner  in  which  the  error 
manifested  itself.  Whether  or  not  a  diagnostic  message  or 
incorrect  problem  output  was  produced  on  subsequent  runs, 
the  error  was  said  to  persist  if  it  remained  uncorrected. 

To  determine  the  number  of  occurrences  of  the  errors, 
both  detected  and  undetected  errors  were  traced  to  their 
origin,  and  counted  on  all  intervening  runs.  Errors  that 
occurred  in  the  source  code  were  traced  back  to  the  run  in 
which  the  compiler  first  analyzed  that  source  code.  Errors 
that  occurred  in  the  input  data  were  traced  back  to  the  run 
in  which  the  program  first  reached  execution  of  an  input 
statement. 

The  errors  occurring  in  each  submission  were  classified 
according  to  five  categories:  general  and  specific  causes. 
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statement  and  phrase  containing  errors,  and  location  of  the 
best  error  detection  information.  The  classified  errors 
were  examined  to  determine  the  number  of  errors  and 
occurrences  of  errors,  as  well  as  the  persistence  of  errors 
and  the  number  of  runs  containing  errors  (hereafter  referred 
to  as  error  runs)  . 

The  persistence  of  an  error  is  a  measure  of  the  number 
of  runs  in  which  an  error  occurred  (i.e.,  from  the  origin  of 
the  error  until  it  was  either  eliminated,  by  correction  or 
removal  from  the  program,  or  the  solution  to  the  problem  was 
submitted) .  It  is  calculated  by  dividing  the  number  of 
occurrences  of  errors  by  the  number  of  errors.  The 
existence  of  errors  in  final  solutions  to  problems  means 
that  persistence  is  only  a  lower  bound  on  the  severity  of 
these  errors  (i.e.,  they  would  have  persisted  for  at  least 
one  more  run) . 

Finally,  we  indicate  the  number  of  runs  that  contained 
any  of  the  errors  that  are  part  of  a  particular  hypothesis 
(i.e. ,  the  number  of  runs  ruined  because  of  a  particular 
language  feature) .  Like  persistence,  error  runs  is  an 
attempt  to  measure  the  severity  of  errors,  rather  than  just 
the  gross  number  of  errors.  An  error  that  persists  for  five 
runs  will  have  error  runs  equal  to  five  while  five  similar 
errors  that  occur  on  the  same  run  will  have  error  runs  equal 
to  one. 
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5 . 4  Statistical  methods 


The  average  numbers  of  errors#  occurrences,  and  error 
runs,  as  well  as  the  average  persistence,  were  calculated 
for  each  language  for  each  hypothesis.  Because  averages 
over  small  samples  can  be  significantly  distorted  by  one  or 
two  very  bad  performances,  a  non- parametric  small-sample 
test  (the  Wilcoxon-Mann-Whitney  test  [Freund  1967  ])  was  used 
to  determine  the  statistical  significance  of  differences. 
Subjects  were  ranked  in  ascending  order,  according  to  their 
number  of  errors  (or  occurrences,  or  error  runs) ,  and  then 
average  ranks  for  the  two  groups  of  subjects  were  compared. 
Similarly,  persistences  were  compared  by  ranking  errors 
according  to  the  number  of  runs  on  which  the  errors 
occurred . 

Both  the  best  and  worst  performances  came  in  the  TOPPS 
group,  and  its  variances  on  all  measures  were  significantly 
higher  than  those  of  the  TOPPSII  group.  Attempts  to  reduce 
variance  by  attributing  it  to  the  varying  ability  of  the 
subjects  as  measured  by  their  examination  grades  failed 
because  there  was  no  significant  relation  between  the  grades 
and  the  number  of  errors  or  occurrences.  Although  the  mean 
examination  grade  of  the  subjects  using  TOPPS  was  higher 
than  that  of  the  subjects  using  TOPPSII,  the  difference  was 
not  statistically  significant. 


27 


6.  Gannon's  results 


6 . 1  Total  errors 

Ten  of  the  25  programmers  who  started  programming  in 
TOPPS  and  15  of  the  26  who  started  programming  in  TOPPSII 
finished  both  programs.  The  difference  in  the  number  of 
subjects  finishing  both  problems  is  only  mildly  significant 
(at  the  <20%  level)  using  the  Chi-square  test  [Freund  1967]. 
As  was  the  case  with  Sime,  Green,  and  Guest,  only  the  errors 
made  by  those  subjects  who  finished  both  problems  were 
considered;  presumably  comparing  the  "best”  40%  of  the  TOPPS 
subjects  with  the  "best"  53%  of  the  TOPPSII  subjects  has 
biased  all  the  following  results  somewhat  in  favor  of  TOPPS. 

A  total  of  3937  occurrences  of  1248  errors  were  found 
and  analyzed.  The  averages  (per  programmer  for  the  number 
of  errors,  occurrences,  and  error  runs,  and  per  error  for 
persistence)  for  errors  of  all  types  in  the  two  languages 
are  summarized  in  the  following  table.  Following  each 
average  is  its  average  rank  (e.g.,  when  the  subjects  were 
ranked  from  1  to  25  according  to  the  number  of  errors  they 
made,  the  TOPPSII  group  ranked  an  average  of  1.50  better 
than  the  TOPPS  group) .  Although  these  figures  tend  to  favor 
the  TOPPSII  group,  only  the  difference  in  occurrences  is 
even  mildly  statistically  significant. 
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TOPPS 


TOPPSII 


Level 


Errors 
Occurrences 
Error  runs 
Persistence 


60.50  (13.90) 
196.00(15.05) 
31.10  (13.65) 
3.24 


42.87(12.40) 
131.80(11.63)  <20% 

28.67(12.57) 

3.07 


The  average  number  of  errors  discovered  at  compile  time 
and  at  run  time,  and  the  average  number  of  undetected 
errors,  are  presented  below.  Again,  although  these  figures 
tend  to  favor  TOPPSII,  none  are  statistically  significant. 

TOPPS  TOPPSII  Level 


Compile  time 
Run  time 
Undetected 


39.30  (13. 80} 
15.60  (14.  20) 
5.60(14.25) 


26.00 (12.47) 
12.27(12.20) 
4.60  (12.17) 


6 . 2  Evaluation  of  individual  design  decisions 

6.2.1  Semicolons 


In  both  languages,  sequencing  is  indicated  by  a 
semicolon.  However,  in  TOPPSII,  semicolons  must  appear 
after  every  statement,  rather  than  only  between  expressions 
as  in  TOPPS.  Although  the  rules  in  each  language  seem 
equally  uniform  and  easy  to  recall,  it  was  felt  that  fewer 
semicolon  errors  would  be  committed  by  the  users  of  TOPPSII 
because  of  the  resemblance  of  rhe  language  to  other 
statement-oriented  languages  (e.g.,  PL/I)  .  As  the  following 
figures  indicate,  significantly  fewer  errors,  occurrences, 
and  error  runs  appeared  in  TOPPSII  programs. 
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TOPPS 


TOPPSII 


Level 


Errors 
Occurrences 
Error  runs 
Persistence 


20.20(17.95) 
28.50  (18.  10) 
8.20  (18.40) 
1.41(119.20) 


2.13(9.70)  <.  5% 

2.47(9.60)  C.5X 

1.73(9.40)  <. 5% 

1.16(106.75) 


Both  languages  use  the  semicolon  as  a  declaration 
terminator.  We  expected  fewer  errors  to  be  made  by  TOPPSII 
programmers,  since  the  use  of  the  semicolon  in  declarations 
and  executable  statements  is  identical.  This  proved  to  be 
the  case. 


Errors 
Occurrences 
Error  runs 
Persistence 


TOPPS 

2.60(16.50) 
3.40  (16.60) 
1  .90(16.75) 
1.31  (17.08) 


TOPPSII 
.40  (10.67) 

.  40  (10.60) 

.  20  (10.50) 
1.00(14.00) 


Level 

<5% 

<5% 

<5% 


6.2.2  Assignment 

Both  TOPPS  and  TOPPSII  use  the  symbol  :=  for  assignment 
and  the  symbol  =  for  comparison  for  equality.  Undoubtedly, 
a  major  cause  of  errors  involving  assignment  is  confusion 
between  the  symbols  :=  and  =.  Many  of  the  subjects  had 
previous  experience  with  languages  that  use  the  symbol  =  to 
denote  both  assignment  and  comparison  (e.g.#  PL/I).  While 
the  number  of  errors  of  this  type  was  not  expected  to 
decrease  among  the  users  of  TOPPSII,  restricting  assignment 
symbols  to  statements  allowed  the  production  of  a  diagnostic 
message  that  was  expected  to  reduce  the  persistence  of  the 


30 


errors. 


The  following  table 


summarizes  the  errors 


attributable  to  assignment  symbols 


TOPPS 


TOPPSII 


Level 


Errors 


2.30(14.35) 


80  (12. 10) 


Occurrences 


16.40(14.95)  1.13(1  1.70) 


Error  runs 


7.00  (15.15) 


80  (11.57) 


<20% 


Persistence  7.13(23.17) 


1.42(8.  08) 


<.1% 


6.2.3  Inheritance  of  environment 

While  we  expected  that  the  scope  rules  of  TOPPSII  would 
cause  more  clerical  and  syntactic  errors  to  be  committed 
than  the  rules  of  TOPPS*  it  was  hoped  that  the  severity  of 
two  types  of  errors  committed  by  the  users  of  TOPPS  would  be 
reduced.  The  first  type  of  error  results  from  inadvertently 
interposing  a  redeclaration  of  a  global  name  in  an  inner 
scope.  This  causes  references  in  the  inner  scope  to  be 
bound  to  a  new  local  variable*  rather  than  to  the  global 
variable.  Failure  to  redeclare  a  global  name  that  was  to  be 
reused  to  identify  a  local  variable*  either  through  omitting 
an  entire  declaration  or  misspelling  the  name  of  the 
variable  in  the  new  declaration*  is  the  second  type  of 


error.  This  causes  references  in  the  inner  scope  to  be 
bound  to  the  global  variable*  rather  than  to  the  new  local 
variable. 

The  scope  rules  of  TOPPSII  certainly  do  not  offer 
complete  protection.  Errors  may  result  either  when  an  inner 
procedure  both  fails  to  specify  inheritance  of  a  global 
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variable  and  reuses  its  name  in  a  local  declaration,  or  when 
an  inner  procedure  specifies  inheritance  of  a  global 
variable  that  it  should  not  be  allowed  to  access.  However, 
these  errors  seem  far  less  likely  than  the  errors  previously 
discussed . 

The  difference  in  the  number  of  errors  favored  TOPPS. 
TOPPSII  had  fewer  average  occurrences,  but  they  involved 
more  programmers,  so  its  average  rank  was  significantly 
greater.  Similarly,  the  difference  in  error  runs  favored 
the  TOPPS  group.  However,  the  persistence  of  the  errors  in 
TOPPSII  programs  was  much  less  than  that  of  TOPPS  programs 
and  the  difference  was  highly  significant. 


TOPPS 

TOPPSII 

Level 

Errors 

.  40(8.  90) 

1  .93(15.73) 

<5% 

Occurrences 

3.90(9.90) 

3.27(15.07) 

<10% 

Error  runs 

1.90(9. 90) 

2.27  (15.07) 

<10% 

Persistence 

9.75(30.75) 

1  .69(15.10) 

<  .5% 

Perhaps 

a  fairer  comparison  is  to  consider  only 

the 

errors  that 

were  not  detected 

syntactically. 

In  this  c 

ase 

all  the  measures  favor  the 

TOPPSII  group 

,  but  only 

the 

difference  in  persistences  is 

mildly  significant. 

TOPPS 

TOPPSII 

Level 

Errors 

.40(13.55) 

.  20  (12.63) 

Occurrences 

3.90(13.60) 

1.33(12.60) 

Error  runs 

1.90  (13.60) 

.  80  (12.60) 

Persistence 

9.75(4.75) 

6.67(3.00) 

<20% 
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6.2.4  Statement  brackets 


The  greater  uniformity  of  the  bracket  structure  of 
TOPPSII  was  expected  to  be  an  advantage  in  reducing  the 
number  of  errors  made.  In  particular*  the  introduction  of  a 
declaration  into  a  parenthesized  construct  results  in  an 
error  in  TOPPS  that  can  not  be  committed  in  TOPPSII. 


TOPPS 

TOPPSII 

Level 

Errors 

1 .40 (16.00) 

.47(11.00) 

<5% 

Occurrences 

2.30(16.90) 

.  53  (1  0.  40) 

<5% 

Error  runs 

1.70(16.75) 

.  53(10.  50) 

<5% 

Persistence 

1 .64  (12.54) 

1.14(7.93) 

<10% 

6.2.5  Expression  evaluation 

Errors  due  to  expression  evaluation  result  from 
misconceptions  about  both  the  direction  in  which  it  proceeds 
and  the  order  in  which  the  operators  are  applied.  If  a 
programmer  were  to  forget  the  direction  in  which  expressions 
are  evaluated*  he  would  not  be  able  to  determine  whether  the 
arithmetic  expression  5-4^3  yields  the  value  -2  (as  it 
does  in  TOPPS) *  or  the  value  4  (as  it  does  in  TOPPSII) •  The 
expression  I  ♦  3  <  J  *  2  illustrates  the  problems  that  arise 
from  the  equal  operator  precedence  of  TOPPS.  This  problem 
is  aggravated  by  the  implicit  conversion  of  logical  values 
to  integers.  In  this  example*  I  and  J  are  both  integer¬ 
valued  variables.  If  J  is  less  than  or  equal  to  one*  the 
sub-expression  3  <  (J*2)  yields  the  value  false  (i.e. * 
numeric  zero) ,  which  is  then  added  to  the  value  of  I.  If  J 
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is  greater  than  one,  the  value  true  (i.  e. ,  numeric  one)  is 
added  to  the  value  of  I.  In  TOPPSII,  the  value  of  this 
expression  is  true  if  (I«-3)<(J*2)  and  false  otherwise. 
During  the  design  of  TOPPSII,  it  was  conjectured  that 
programmers  would  make  fewer  and  less  persistent  errors 
using  the  traditional  method  of  expression  evaluation. 
While  no  expression  evaluation  errors  were  found  in  TOPPSII 
programs,  five  errors  were  located  in  TOPPS  programs. 


TOPPS 

TOPPSII 

Level 

Errors 

. 50(16.75) 

.00  (10.50) 

<5% 

Occurrences 

4.30(16.75) 

.  00  (10.50) 

<5% 

Error  runs 

4.30(16.75) 

.00  (10.50) 

<5% 

Persistence 

8.60 

— 

6.2.6  Relation 

-connectors 

In  TOPPS, 

the  operators 

& ,  |  ,  and 

perform  two 

functions:  to 

connect  logical 

relations,  and 

as  masking 

operators  to 

pack  multiple  values  into  single 

words.  While 

the  -»  operator  is  retained  in  TOPPSII,  the  &  and  |  operators 
have  been  replaced  by  the  built-in  functions  all  and  any 
respectively.  These  functions  take  lists  of  arguments, 
which  must  be  logical  relations,  and  return  a  logical  value. 
In  both  languages,  multiple  values  may  still  be  packed  into 
a  single  word  using  arithmetic  operators. 

Although  more  syntactic  errors  may  occur  because  of  the 
extra  symbols  required  by  the  relation-connectors  in 
TOPPSII,  it  was  hoped  that  the  persistence  of  two  kinds  of 
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These 


errors  made  by  the  users  of  T0PP5  would  be  reduced, 
errors  involve  misunderstandings  about  the  value  produced  by 
the  Boolean  operators  of  TOPPS  and  the  rules  for  expression 
evaluation  involving  these  operators.  Often  the  two  roles 
of  &  and  |  are  confused.  This  results  in  misunderstanding 
the  value  of  expressions  such  as  the  one  below,  which  is 
true  only  when  the  value  of  I  is  6  (i.e.,  the  "logical  or6s 
of  the  two  binary  numbers  2  and  4)  . 


if  I  =  2  |  4  then  . . . 


It  was  also  expected  that  errors  resulting  from  confusion 
about  the  order  of  evaluation  of  expressions  containing 
relation-connectors  would  be  both  less  common  and  less 
severe  in  TOPPSII  than  in  TOPPS.  It  was  thought  that  the 
rule  for  function  evaluation  was  easier  to  remember  than 
that  for  expression  evaluation  in  TOPPS.  The  only  errors 
observed  in  TOPPS  were  those  involving  the  order  of 
expression  evaluation. 


Errors 
Occurrences 
Error  runs 
Persistence 


TOPPS 
.  20(13.50) 
2.30(13.70) 
2.30  (13.7  0) 
11.50  (3.50) 


TOPPSII 
.  13  (12.67) 
.  13  (12.53) 
.  13  (12.53) 
1 .00(1.50) 


Level 


<20% 


6.2.7  Additional  statements 


The  results  of  providing  constant  identifiers  and  case 
and  for  statements  were  inconclusive  for  two  reasons. 
First,  the  hypotheses  concerning  the  relevant  errors  were 
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too  broad  (e.g.,  any  error  in  selection).  Also,  substitutes 


for  these 

constructs 

were 

available  in  both  languages  and 

were  used 

heavily. 

while 

the  new  constructs  were  not 

frequently 

used  in 

TOPPSII 

•  Below  is  a  table  summarizing 

the  average 

number  of 

the  different  types  of  statements  used 

on  each  run. 

TOPPS 

TOPPSII 

constant 

— 

1.79 

if 

8.36 

7.76 

case 

— 

.50 

repeat 

7.76 

6.15 

for 

— 

.40 

6.2.8  Other 

errors 

9e  expected  that  the  errors  that  were  not  attributable 
to  any  of  our  design  decisions  would  be  comparable  in  the 
two  languages.  The  following  figures  summarize  these 
errors.  The  differences  in  errors,  occurrences,  and  runs 
all  favor  TOPPS,  but  only  the  number  of  errors  is  even 
mildly  significant.  The  difference  in  persistences  favors 


TOPPS II. 

Errors 
Occurrences 
Error  runs 
Persistence 


TOPPS 

22.50(10.  45) 
77.00(12.70) 
24.20  (12.65) 
3.42 


TOPPSII  Level 

28.47(14.70)  <20% 

81.27  (13.20) 

25.20  (13.23) 

2.85  <10% 


36 


6.2.9  Summary  of  results 


The  following  table  summarizes  the  statistically 
significant  results  obtained  in  the  evaluation  of  the  major 
hypothesis  and  each  of  the  nine  subhypotheses  of  the  study. 


Hypothesis 

Measure 

Direction 

Level 

All  errors 

Occurrences 

TOPPSII 

<20% 

Semicolons 

Executable  stmts 

Errors 

TOPPSII 

< .  5% 

Occurrences 

TOPPSII 

<  .  5% 

Error  runs 

TOPPSII 

< .  5% 

Declarations 

Errors 

TOPPSII 

<5% 

Occurrences 

TOPPSII 

<5% 

Error  runs 

TOPPSII 

<5% 

Expression  evaluation 

Errors 

TOPPSII 

<5% 

Occurrences 

TOPPSII 

<5% 

Error  runs 

TOPPSII 

<5% 

Relation- connectors 

Persistence 

TOPPSII 

<20% 

Assignment 

Error  runs 

TOPPSII 

<20% 

Persistence 

TOPPSII 

<.1% 

Environment  inheritance 

Syntax  errors 

Errors 

TOPPS 

<5% 

included 

Occurrences 

TOPPS 

<10% 

Error  runs 

TOPPS 

<10% 

Persistence 

TOPPSII 

<«  5% 

Syntax  errors 
excluded 

Persistence 

TOPPSII 

<20% 

Statement  brackets 

Errors 

TOPPSII 

<5% 

Occurrences 

TOPPSII 

<5% 

Error  runs 

TOPPSII 

<5% 

Persistence 

TOPPSII 

<10% 

Constants 

Persistence 

TOPPSII 

<5% 

Selection  statements 

Errors 

TOPPSII 

<10% 

Occurrences 

TOPPSII 

<20% 

Iteration  statements 

Errors 

TOPPSII 

<20% 
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6.2.10  Learning 


Perhaps  the  most  serious  limitation  of  this  study  is  its 
treatment  of  learning.  Several  of  the  language  design 
decisions  were  made  to  take  advantage  of  the  subjects* 
previous  experience  with  mathematics  and  other  programming 
languages.  A  crude  measure  of  this  effect  can  be  observed 
in  the  following  tables.  The  columns  indicate  the 
percentage  of  relevant  errors,  relative  to  the  total  number 
of  errors,  that  occurred  in  the  first  and  second  halves  of 
program  development  respectively.  The  division  of  errors 
that  occurred  in  the  first  half  of  the  runs  compared  to 
those  that  occurred  in  the  second  half  was  511-167  in  TOPPS 
and  539-200  in  TOPPSII. 


TOPPS 


Error 

First 

Second 

Semicolon 

Declarations 

4.  5% 

1 . 8% 

Executable  statements 

36.8% 

12.6% 

Expression  evaluation 

1.096 

1.296 

Relation- connectors 

0.4% 

0.6% 

Assignment 

3.7% 

8.4% 

Statement  brackets 

2.  3% 

1.2% 

Inheritance  of  environment 

0.8% 

1.896 

Other  errors 

50.5% 

100.0% 

72.5% 

ioo7i% 
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TOPPSII 


Error 

First 

Second 

Semicolon 

Declarations 

1.1% 

0.0% 

Executable  statements 

5.6% 

1.0% 

Expression  evaluation 

0.0% 

0.0% 

Relation-connectors 

0.4% 

0.0% 

Assignment 

1.9% 

1.0% 

Statement  brackets 

0.9% 

1.0% 

Inheritance  of  environment 

3.9% 

4.0% 

Other  errors 

86.3% 

ioo7i% 

93.0% 

100.0% 

The  interesting  errors  are  those  whose  percentages  increased 
or  remained  large  during  the  second  half  of  program 
development  despite  the  nature  of  the  runs  during  this 
period  (e.g.#  polishing  output  or  adding  comments) • 
Subjects  do  not  cope  with  these  errors  nearly  as  well  as 
with  those  that  violate  the  syntax  of  the  language. 

6.3  I  implications  for  language  design 

This  experiment  shows  that#  at  least  in  one  environment# 
several  language  design  decisions  affected  reliability 
significantly.  TOPPS  had  been  used  "satisfactorily98  for 
several  years#  and  each  of  its  bad  features  is  shared  with 
other#  more  widely-used  languages.  Yet  a  few  simple  changes 
produced  striking  results. 

In  using  the  semicolon  as  a  separator#  rather  than  as  a 
statement  terminator#  TOPPS  was  following  a  long  and 
honorable  tradition  .(ALGOL  60#  Pascal#  BLISS#  etc.). 
However#  the  TOPPSII  form  (similar  to  that  of  PL/I)  led  to 
an  order  of  magnitude  reduction  in  the  number  of  semicolon 
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errors.  Of  course,  most  semicolon  errors  are  rather  trivial 
(i.e.,  they  generally  do  not  persist  more  than  one  run). 
However,  a  small  modification  to  the  language  would  have 
eliminated  errors  that  occurred  on  more  than  a  quarter  of 
all  compilations.  It  is  also  interesting  to  note  that  over 
14%  of  the  second-half  TOPPS  errors  are  still  semicolon 
errors  (compared  to  1%  for  TOPPSII)  • 

At  the  other  end  of  the  scale  are  four  classes  of 
infrequent  errors  with  very  high  persistence:  assignment 
errors,  inheritance  of  environment  errors,  expression 
evaluation  errors,  and  relation-connector  errors.  The 
persistence  of  each  of  these  classes  of  errors  in  TOPPS  was 
about  half  the  total  number  of  runs  needed  to  complete  a 
program.  It  is  reasonable  to  assume  that  these  errors  would 
be  even  more  persistent  in  larger  programs,  adding  even 
greater  weight  to  the  already  significant  improvements  made 
by  TOPPSII.  Furthermore,  the  relative  frequencies  of  these 
four  classes  of  errors  in  TOPPS  approximately  doubled  in  the 
second  half,  making  it  seem  unlikely  that  they  are  solely 
due  to  unfamiliarity. 

The  persistence  of  assignment  errors  in  TOPPS  calls  into 
serious  question  the  treatment  of  the  assignment  symbol  := 
as  "just  another  operator."  Expression-oriented  languages 
using  this  convention  (e.g.,  ALGOL  68)  may  cause  unsuspected 
reliability  problems.  Other  expression-oriented  languages 
using  an  assignment  operator  quite  different  from  =  (e.g.. 
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<-  in  APL  [API  1970]  and  BLISS)  probably  avoid  some  of  these 
errors,  but  provide  no  better  error  detection® 

The  TOPPSII  restrictions  on  inheritance  of  environment 

ft 

reduced  the  persistence  of  subtle  errors  (i®  e* ,  those  that 
could  not  be  detected  syntactically)  at  the  cost  of 
introducing  a  few  trivial  errors®  This  would  seem  to 
support  the  claim  that  the  unrestricted  use  of  global 
variables  is  harmful  [ Wulf  and  Shaw  1973].  However,  the 
high  persistence  of  the  subtle  TOPPSII  errors  also 
demonstrates  that  the  simple  restrictions  on  inheritance  of 
environment  are  not  sufficient  to  prevent  these  errors  from 
occurring . 

The  expression  evaluation  rules  of  TOPPS  are  similar  to 
those  of  APL®  Only  two  programmers  (one  in  each  group)  had 
previously  programmed  in  APL,  while  all  but  one  had 
experience  using  some  language  (not  to  mention  mathematics) 
with  left-to-right  evaluation  and  traditional  operator 
precedence.  Thus  the  greater  frequency  of  errors  in  TOPPS 
may  be  at  least  partially  explained  in  terms  of  prior 
experience.  However,  the  high  persistence  of  these  errors 
seeas  incompatible  with  the  claims  for  the  benefits  of 
“naturalness85  sometimes  made  for  the  APL  rules.  Similarly, 
errors  involving  infix  relation-connectors  seem  to  be 
difficult  to  find  and  remove® 
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7 .  Conclusions 

There  is  no  reason  to  suppose  that  languages  designed 
without  explicit  concern  for  reliability  will  be  suitable 
for  the  production  of  reliable  software.  Each  of  the  major 
programming  languages  has  flaws  that  can  be  expected  to 
reduce  the  reliability  of  programs.  Many  alternative 
features  have  been  proposed  to  reduce  the  frequency  and/or 
persistence  of  errors,  and  there  is  now  empirical  evidence 
to  support  the  usefulness  of  some  of  them.  However,  there 
is  still  much  to  be  done,  both  in  the  design  of  languages 
for  reliable  software,  and  in  the  experimental  evaluation  of 
language  design  decisions,  particularly  to  discover  the 
effects  of  different  environments. 
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0 .  Abstract 


The  specification  of  the  manner  in  which  software  is 
intended  to  behave  has  a  vital  role  to  play  in  the 
attainment  of  reliable  software.  To  be  most  useful,  a 
specification  should  meet  generality,  specificity,  and 
perspicuity  requirements.  Section  2  of  this  paper  describes 
and  discusses,  in  the  context  of  these  criteria,  the 
advantages  and  drawbacks  of  procedural  and  descriptive 
specification  techniques.  In  Section  3  an  alternative 
technique,  dyadic  specification,  is  presented.  This 
technique,  which  couples  procedural  and  algebraic 
approaches,  is  explained  both  abstractly  and  via  an  example. 
A  mechanism  to  facilitate  its  use  is  also  discussed. 
Section  4  outlines  the  potential  impact  of  this  technique  on 
the  processes  of  structured  specification,  structured 
design,  proofs  of  correctness,  and  testing.  The  issue  of 
confidence  in  the  reliability  of  software  is  discussed  in 
the  Conclusion.  Appendix  1  formalizes  some  terms  used 
informally  in  Section  3.  Appendix  2  gives  some  sample 
axiomatic  Type  definitions. 
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1 .  The  Problem 


That  the  utility  of  software  varies  directly  with  its 
reliability  is  clear.  To  be  well-founded*  confidence  in  the 
reliability  of  a  piece  of  software  must  be  based  upon  three 
factors: 

1)  Knowledge  of  how  the  program  will  behave* 

2)  Knowledge  of  how  the  program  should  behave. 

3)  A  method  for  comparing  this  knowledge. 

A  knowledge  of  how  a  program  will  behave  in  the  future  can 
be  based  on  either  a  study  of  the  program8 s  past  behaviour 
(testing)*  a  direct  analysis  of  the  program  text  •  (“proofs85 
of  correctness) *  or  a  combination  of  the  two.  While  both 
test  and  proof  methodologies  are  interesting  and  important 
topics*  neither  is  the  central  subject  of  this  paper*  and 
shall  therefore  be  only  tangentially  dealt  with. 

The  primary  subject  of  this  paper  is  the  problem  of 
stating  how  a  given  software  product  is  supposed  to  behave. 
Essential  to  the  attainment  and  especially  to  the 
communication  of  such  an  understanding  is  the  ability  to 
express  what  a  piece  of  software  is  supposed  to  do.  That  is 
to  say*  to  specify  the  problem  it  is  intended  to  solve*  or 
rather  that  “problem”  with  which  those  responsible  for  the 
production  of  the  software  are  confronted. 
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Problem  specifications  may  take  many  forms,  but  all  good 
specifications  have  certain  attributes  in  common.  A  good 
specification  must  be  restrictive  enough  to  ensure  that  no 
unacceptable  program  will  meet  the  specification.  A  good 
specification  must  also  be  sufficiently  general  to  ensure 
that  few  (if  any)  acceptable  programs  are  precluded.  It  is 
not  essential  to  ensure  that  no  acceptable  solution  is 
precluded,  but  when  one  places  unnecessary  constraints  on 
the  solution,  one  runs  the  risk  of  eliminating  some  of  the 
more  desirable  (e.g.,  more  efficient)  solutions.  And 
finally,  a  good  specification  must  be  perspicuous  enough  to 
permit  a  high  degree  of  confidence  in  its  aptness. 


2 .  An  Overview  of  Specification  Techniques 

As  previously  noted,  problem  specifications  may  take 
aany  forms.  Most,  however,  may  be  placed  in  one  of  two 
categories:  procedural  or  descriptive.  Each  mode  of 
specification  offers  significant  advantages  and  significant 

drawbacks. 

"Do  X,  then  Y,  and  finally  Z,  and  what  results  is  that 
thing  which  I  am  trying  to  specify,'9  is  an  example  of  a 
procedural  specification.  Instead  of  trying  to  abstractly 
define  the  article  in  question,  one  gives  a  recipe  for 
constructing  it.  In  many  cases,  this  is  by  far  the  easiest 
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way  to  specify  something;  in  part  because  we  have  at  our 
disposal  better-developed  solution  specification  techniques 
(e.g.,  programs)  than  problem  specification  techniques. 

The  obvious  structural  similarity  between  a  procedural 
specification  of  a  problem  and  an  implementation  of  a 
solution  is  a  mixed  blessing.  Because  of  their  similarity, 
a  procedural  specification  often  leads  quite  naturally  to  an 
implementation.  In  addition  to  reducing  the  cost  of 
implementation,  this  tends  to  simplify  the  problem  of 
demonstrating  that  the  implementation  does  indeed  meet  the 
specification.  Unfortunately,  should  the  specification 
itself  be  incorrect  or  insufficient,  the  ease  with  which  it 
may  be  transformed  into  an  implementation  becomes  rather 
more  a  bane  than  a  boon.  Errors  and  inconsistencies  tend  to 
be  propagated  rather  than  detected;  forgotten  cases  tend  to 
remain  forgotten.  The  probability  of  error  is  particularly 
high  in  the  specification  of  complex  software.  Such 
specifications  are  most  often  either  not  sufficiently 
detailed  to  eliminate  ail  unacceptable  implementations,  or 
too  long  to  permit  substantial  confidence  in  their  aptness. 
Even  if  one  could  overcome  these  problems,  procedural 
specifications  would  suffer  from  the  drawback  of  often 
failing  to  meet  the  generality  criterion  discussed  above. 

In  a  descriptive  specification,  one  lists  the  properties 
that  the  object  being  specified  is  to  possess.  Instead  of 
implicitly  defining  the  end  product  via  a  recipe  for  its 
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preparation,  one  defines  it  directly  by  describing  what  the 
end  product  should  be.  For  most  software,  this  turns  out  to 
be  a  description  of  its  behaviour.  Such  specifications  tend 
to  define  software  quite  generally  in  that  only  essential 
characteristics  are  specified.  It  may  thus  be  viewed  as  an 
abstraction  encompassing  a  relatively  large  (compared  to  a 
procedural  specification)  class  of  implementations.  Because 
descriptive  specifications  tend  to  differ  radically  from 
implementations  of  the  abstractions  they  define,  the 
implementation  process  often  serves  to  point  up  flaws  in  the 
specification.  The  situation  is  much  like  that  described  by 
Hoare  and  Lauer  in  their  argument  for  complementary 
definitions  of  programming  languages  (Hoare  1973).  In  spite 
of  these  advantages,  complete  descriptive  specifications  of 
complex  software  are  far  from  common  —  primarily  because  of 
the  difficulty  involved  in  constructing  them.  Part  of  the 
problem  stems  from  the  paucity  of  useful  tools  to  aid  in 
such  specifications.  If  the  problem  one  wishes  to  specify 
is  not  mathematical  in  nature,  the  lack  of  an  appropriate 
language  in  which  to  couch  a  descriptive  specification 
becomes  particularly  burdensome.  One  final  problem 
associated  with  descriptive  specifications  is  that  they  give 
the  implementor  little  or  no  direction. 
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3 .  Dyadic  Specification 

In  the  previous  section  I  indicated  that  neither 
procedural  nor  descriptive  specification  techniques  have 
proved  to  be  totally  satisfactory.  In  this  section,,  I  shall 
propose  a  technique  that  is  essentially  a  combination  of.  the 
two  --  intended  to  preserve  the  virtues  and  minimize  the 
faults  of  both. 

One  begins  with  a  very  high-level  implementation  of  the 
software  to  be  specified.  It  should  be  as  high-level  as 
possible  consonant  with  being  specific  enough  to  ensure  that 
all  unacceptable  programs  are  eliminated.  To  achieve  this 
level  of  specificity  all  functions  to  be  performed  by  the 
final  product  must  be  included,  and  all  symbols  that  appear 
must  be  well-defined.  For  a  symbol  to  be  well-defined,  its 
exact  meaning  must  either  be  known  a  priori  or  supplied 
elsewhere  in  the  specification.  In  most  cases,  to  use  only 
symbols  whose  meanings  are  a  priori  known  will  prove  self- 
defeating.  If  there  exists  a  special-purpose  description 
language  that  is  appropriate  to  the  problem  one  is  grappling 
with  (e.g. a  if  one  is  dealing  with  a  set  theoretic  problem), 
one  might  get  away  with  using  only  generally  known  symbols. 
Unfortunately,  this  is  rarely  the  case.  And  if  it  is  not, 
the  attempt  to  use  only  symbols  whose  meaning  is  known  a 
pri  ori  will  lead  to  a  rather  low-level  "high-level 
specification."  It  will  be  too  lengthy  to  be  perspicuous. 


53 


In  short,  it  will  have  all  the 


and  extremely  inflexible, 
problems  I  have  associated  with  procedural  specifications. 
One  is  thus  forced  to  introduce  new  high-level  symbols 
(generally  operations  and  data  objects)  whose  meaning  will 
have  to  be  defined. 

It  is  as  a  mechanism  for  these  definitions  that  the 
descriptive  aspect  of  the  dyadic  specification  method  comes 
into  play.  The  introduction  of  new  operations  and  the 
introduction  of  new  data  objects  are  inextricably  bound. 
One  makes  sense  only  in  terms  of  the  other.  If  one 
introduces  a  new  type  of  data  object,  it  becomes  useful  only 
when  one  has  supplied  operations  in  which  objects  of  that 
type  may  play  a  role  (Guttag  1974).  If  one  introduces  a  new 
operation,  one  must  either  introduce  a  new  data  type  or 
augment  the  definition  of  an  old  data  type  by  explaining  the 
interaction  of  objects  of  that  type  with  the  new  operation. 
So,  one  is  always  dealing  with  a  set  of  values  and  a  set  of 
operations,  i.e. ,  an  algebraic  system.  This  sort  of  "type 
algebra”  plays  an  important  role  in  Simula  67  (Dahl  1968) 
and  related  languages,  e.g.,  CIO  (Liskov  1974)  and  ALPHARD 
(Wulf  1974).  Operations  are  syntactically  associated  with 
each  other  and  with  data  objects  via  class  definitions. 
These  operations  are  then  imbued  with  meaning  via 
implementations.  As  a  specification  technique,  this  has  all 
of  the  problems  discussed  above.  By  explicitly  presenting  a 
class  as  an  algebra,  however,  and  defining  it  abstractly  by 
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specifying  its  algebraic  characteristics*  these  problems  can 
be  avoided. 

Consider  the  problem  of  specifying  a  symbol  table  and 
the  operators  upon  it  for  use  in  a  compiler  for  an  ALGOL- 
like  language.  A  convenient  set  of  operations  might  be: 

1)  INIT  —  Create  an  empty  symbol  table. 

2)  ?EMPTY?  —  Is  there  an  identifier  in  the  symbol 
table? 

3)  ENTER_BLOCK  --  Note  a  block  entry  (e.g.*  place  a 
block  mark)  in  symbol  table. 

4)  LEAVE_BLOCK  --  Note  a  block  exit  in  symbol  table. 

5)  ADD  —  Add  an  identifier  and  its  attributes  to  the 
symbol  table. 

6)  ATTRIBUTES  --  Return  the  attributes  of  a  specified 
identifier. 

7)  7IMBL0CK?  --  Has  the  specified  identifier  already 
been  declared  in  this  scope? 

Conventionally*  these  operations  would*  when  used  in  a  high- 
level  specification*  either  go  undefined  or  be  defined  by  a 
specific  data  structure  and  set  of  access  routines.  The 
algebraic  approach  is  in  distinct  contrast  to  this.  It 
might  *  for  example*  lead  to  the  following  set  of  relations. 

{  A  few  words  about  the  form  of  these  relations:  The 
capitalized  words  denote  the  operations  described  above*  the 
underlined  words  are  keywords  whose  meaning  should  be 
obvious*  “true56  and  “false’6  are  constants  known  to  the 
operations  on  type  boolean*  and  all  other  uncapitalized 
words  are  typed  free  variables.  A  formal  description  of  the 
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language  used  in  the  presentation  of  this  and  subsequent 
axiom  sets  is  contained  in  Appendix  1.) 

7EMPTY? (INIT)  =  true 

? EMPTY? (ENTER_BLOCK (sym_tab) )  =  7EMPTY?  (sym_tab) 

7EMPTY? (ADD (sym_tab, id, attrs)  )  =  false 

LEAVE_BLOCK (INIT)  =  error 

LEAVE_BLOCK (ENTER_BLOCK(sym_tab) )  =  sym_tab 
LEAVE_3L0CK (ADD(sym_tab, id, attrs) )  =  LEAVE_BLOCK (sym_tab) 

ATTRIBUTES  (INIT, id)  =  error 

ATTRIBUTES (ENTER_BLOCK  (sym_tab) , id)  =  ATTRIBUTES (sym_tab, id) 
ATTRIBUTES  (ADD (sym_tab, id , at trs) ,id«)  = 

if  7EQUAL?  (id ,  id 1 )  /*vhere  7EQUAL?  is  an 

operation  assumed  to  bs 
defined  for  objects  of 
type  identifier  */ 

then  at trs 

else  ATTRIBUTES (sym_tab, id') 

7INBL0CK? (INIT, id)  =  false 

7IHBL0CK?  (ENTER__BLOCK  (sym_tab)  ,  id)  =  false 
7 INBLOCK?  (ADD (sym_tab ,id, attrs)  ,id#)  = 
if  7EQUAL?  (id, id® ) 
then  true 

else  7INBL0CK?  (sym_tab ,id* ) 
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A  set  of  relations  such  as  the  above  serves  a  dual 
purpose.  Not  only  does  it  define  an  abstract  data  type  that 

can  be  used  in  the  specification  of  other  parts  of  the 

compiler,  but  it  also  provides  a  complete,  self-contained, 
specification  for  a  major  subsystem  of  a  compiler.  The 
extent  to  which  the  above  specification  completely  captures 
and  ^encapsulates  an  appropriate  (to  the  application)  notion 
of  type  symbol  table  is  illuminated  when  one  considers  the 
problem  of  specifying  a  compiler  for  a  slightly  different 
language  —  say  one  with  block  structure  but  without 

inherited  scope.  The  necessary  changes  in  the  specification 
of  the  compiler  would  be  entirely  localized  within  the 

axiomatization  of  the  symbol  table.  More  specifically,  one 
would  merely  have  to  redefine 

ATTRIBUTES (ENTER_BLQCK(sym_tab) ,id) 
as  being  identically  S!errorw  --  thus  indicating  that  only 
the  most  local  block  is  to  be  searched. 

The  most  serious  problem  with  this  sort  of  algebraic 
specification  technique  lies  in  the  fact  that  appropriate 
sets  of  relations  are  often  difficult  to  construct.  In  an 
attempt  to  ameliorate  this  problem,  I  have  begun  work  on  a 
system  to  aid  the  programmer  in  the  initial  specification  of 
an  axiomatic  definition  of  the  operations  on  an  abstract 
data  type,  and  to  mechanically  verify  the  “'completeness88  and 
consistency  of  that  specification.  As  the  first  step  in 
defining  a  new  type,  the  programmer  would  supply  the  system 
with  the  names,  ranges,  and  domains  of  all  primitive 
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operations  to  be  permitted  on  that  type.  Given  this 
preliminary  specification,  the  system  would  begin  to  prompt 
the  programmer  to  supply  the  additional  information 
necessary  for  the  system  to  derive  a  "complete"  axiom  set 
for  the  operations.  This  information  might  take  the  form  of 
individual  axioms  about  the  operations  (e.g., 
? EMPTY? (INIT)  =  true)  or  meta-axioms  describing  some  facet 
of  the  axiom  set  to  be  derived  (e.g.,  that  it  is  to  be  a 
superset  or  instance  of  the  axiom  set  for  another  type) . 

The  keys  to  the  success  of  such  a  system  are  two:  It 
must  be  able  to  recognize  a  "suf ficiently-comple te" 
definition  when  it  has  one  (though  not  necessarily  all  such 
definitions) ,  and  it  must  be  able  to  direct  the  programmer 
as  to  what  information  would  be  sufficient  to  turn  a  not 
recognizably  suff iciently-complete  definition  into  a 
recognizably  suf f iciently-complete  one.  A  more  detailed 
discussion  of  the  notion  of  "suff iciently-complete"  is 
contained  in  Appendix  1. 


4.  Impact  on  Reliability 

The  impact  of  this  specification  technique  on  the 
problem  of  producing  reliable  software  may  be  partitioned 
into  four  interrelated  categories. 
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4.1. 


Structured  Specification 


A.s  I  have  emphasized*  this  specification  technique  can 
play  a  vital  role  in  the  formulation  of  clear  and  precise 
problem  specifications.  Many  complex  systems  may  be  viewed 
as  instances  of  the  sort  of  type  algebra  I  have  been 
discussing.  If  one  were  to  provide  axioms  defining  the 
relationships  among  all  the  operations  in  an  inventory 
control  system*  for  example*  one  would  have  fully  specified 
the  problem  to  be  solved.  For  software  that  is  not 
conveniently  characterized  algebraically*  type  algebras 
provide  a  mechanism  for  abstracting  complex  subsystems  so 
that  the  overall  system  may  be  more  easily  described  via 
procedural  methods. 

I  have  thus  far  confined  my  discussion  and  examples  to 
two-level  specifications.  In  practice*  there  is  no  reason 
to  impose  such  a  restriction.  Let  us  again  refer  to  the 
symbol  table  example.  This  time  we  shall  assume  that  the 
language  to  be  compiled  permits  the  inheritance  of  global 
variables*  but  only  if  they  appear  in  a  ,e  knows  iist*as  which 
lists*  at  block  entry*  all  non-local  variables  to  be  used 
within  the  block  (Gannon  1974) .  The  symbol  table  operations 
in  a  compiler  for  such  a  language  would  be  much  like  those 
already  discussed.  The  only  difference  visible  to  parts  of 
the  compiler  other  than  the  symbol  table  cluster  would  be  in 
the  ENTER_BLOCK  operation:  It  would  have  to  be  altered  to 
include  an  argument  of  abstract  type  OQWS_LIST.  iithin  the 
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definition  of  the  type,  all  relations,  and  only  those 
relations,  that  deal  with  the  ENTER_BLOCK  operation  would 
have  to  be  altered.  An  appropriate  set  of  relations  would 
be: 


7EMPTY?  (ENTER_BLOCK  (sym_tab, k_list)  )  =  ?EMPTY?  (sym_tab) 

LEAVE_BLOCK (ENTER_BLOCK (sym_t ab,k_list)  )  =  sym_tab 

ATTRIBUTES  (ENTER_BLOCK (sy m_tab, k_list )  ,id)  = 
if  ?IN?  (k_list ,  id) 

then  ATTRIBUTES (sym^tab, id) 
else  error 

? INBLOCK? (ENTER_BLOCK (sym_tab,k_list)  , id)  =  false 

Note  that  the  above  relations  are  not  well-defined  in 
that  the  undefined  symbol  "?IN?,”  which  is  an  operation  on 
the  abstract  type  KNOWS_LIST,  appears  in  relations  dealing 
with  the  ATTRIBUTES  operation.  The  solution  to  this  problem 
is  simply  to  add  another  level  to  our  specification  by 
supplying  a  definition  of  the  type  KNOWS_LIST.  An 
appropriate  set  of  operations  might  be: 

1)  CREATE  —  Create  an  empty  knows  list. 

2)  APPEND  —  Add  an  identifier  to  a  knows  list. 

3)  ?IN?  —  Is  the  specified  identifier  in  the  knows 
list? 
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These  operations  could  be  defined  by  the  following 
relations: 

?IN?  (CREATE)  =  false 

?IN? (APPEND (k_list, id) , id9)  = 
if  ?EQUAL?  (id 9 id® ) 
then  true 

else  ?IN? (k_list, id® ) 

Alternatively,  of  course,  one  could  elect  to  define  these 
operations  completely  procedurally  or  via  a  dyadic 
sped  fication . 


4 .  2 .  Structured  Des ign 

The  multi-level  structured  specifications  discussed 
above  have  much  in  common  with  the  top-down  structured 
designs  advocated  (though  rarely  practiced)  by  most  people 
working  in  the  area  of  computer  program  engineering.  In 
fact,  its  use  as  a  tool  for  the  top-down  design  of  software, 
may  well  prove  to  be  the  most  important  application  of  the 
dyadic  specification  technique.  The  application  of  this 
technique  to  top-down  design  is  a  simple  recursive  process: 

1)  Perform  a  dyadic  specification  of  the  problem, 
Ose  the  technique  as  outlined  above. 
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2)  Take  every  algebraically  defined  subsystem  and, 
treating  it  as  an  independent  system,  apply  to  it  the 
process  currently  being  described. 

3)  Continue  until  all  lowest-level  specifications 
are  completely  procedural  and  contain  no  symbols  that  are 
not  a  £riori  known  to  an  available  compiler.  I.e.,  until 
one  has  an  implementation. 


4.3.  Proofs  of  Correct  ness 

If  an  entire  piece  of  software  has  been  described  as  a 
single  algebraic  system,  the  relations  that  define  the 
algebra  provide  exactly  those  assertions  that  must  serve  as 
the  ultimate  goal  of  the  proof.  The  value  of  having  such  a 
set  of  assertions  available  should  be  apparent  to  anyone  who 
has  attempted  to  construct,  a  posteriori,  assertions 
appropriate  to  a  correctness  proof  for  an  already-written 
program.  In  multi-level  pr ocedurally-oriented 
specifications,  the  algebraic  definition  of  abstract 
operations  provides  powerful  rules  of  inference  that  may  be 
used  to  prove  the  correctness  of  the  procedures  in  which  the 
abstract  operations  appear.  That  is  to  say,  the  presence  of 
algebraic  definitions  of  subsystems  provides  a  mechanism  for 
proving  an  implementation  to  be  correct  modulo  the  abstract 
operations  it  uses.  The  correctness  of  an  implementation  of 
such  a  subsystem  may  then  be  established  independently  by 
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proving  that  it  does  indeed  satisfy  the  assertions  utilized 
at  a  higher  level. 


4.4.  Testing  and  Robustness 

I  have  specified  and  am  currently  designing  and 
implementing,  with  the  help  of  the  techniques  described  in 
this  paper,  a  system  in  which  implementations  and  algebraic 
specifications  of  abstract  types  are  interchangeable.  In 
the  absence  of  an  implementation,  abstract  operations  are 
interpreted  symbolically.  Thus,  except  for  a  significant 
loss  in  efficiency,  the  lack  of  an  implementation  is 
completely  transparent  to  the  user.  The  system  currently 
under  development  will  be  used  primarily  as  a  vehicle  for 
facilitating  the  testing  of  software. 

Though  systems  have  occasionally  been  designed  in  a  top- 
down  fashion,  they  have  for  the  most  part  been  tested  from 
the  bottom  up.  This  was  necessary  because  the  upper  levels 
could  not  be  executed  in  the  absence  of  an  implementation  of 
lower  levels.  By  eliminating  the  necessity  of  supplying 
such  implementations,  this  system  will  remove  that 
inhibition.  It  will  also  lead  to  better  and  easier 
modularization  of  testing.  Much  of  the  need  for  inter¬ 
programmer  cooperation  will  be  eliminated.  One  need  no 
longer  delay  testing  while  awaiting  the  implementation  of 
other  modules.  More  importantly,  if  one  executes  with 
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specif ications  rather  than  implementations  of  abstract 
operations,  the  possible  sources  of  a  known  bug  are  far  more 
limited.  It  should  be  noted  that  in  many  ways  the  goals  of 
this  system  are  closely  related  to  those  outlined  by  Parnas 
in  his  description  of  SODAS  (Parnas  1967).  The  systems 
themselves,  however,  are  quite  different  from  one  another. 
The  most  outstanding  differences  stem  from  SODAS® s  reliance 
on  procedural  specifications  for  those  operations  that  are 
to  be  simulated. 

Parnas  (Parnas  1972)  has  emphasized  the  advantages  of 
restricting  the  information  available  to  individual 
programmers.  If  a  programmer  is  supplied  with  algebraic 
definitions  of  the  abstract  operations  available  to  him,  and 
forced  to  write  and  test  his  module  with  only  that 
information  available  to  him,  he  is  denied  the  opportunity 
to  rely  intentionally  or  accidently  upon  information  that 
should  not  be  relied  upon.  This  not  only  serves  to  localize 
the  effect  of  implementation  errors,  but  also  to  increase 
the  ease  with  which  one  correct  implementation  may  be 
replaced  by  another. 

In  the  above  discussion,  I  have  emphasized  the 
advantages  to  be  gained  by  substituting  a  specification  for 
an  implementation.  Though  the  system  I  am  working  on  does 
not  incorporate  it,  there  are  tremendous  advantages  to  be 
gained  by  supplementing  an  implementation  with  a 
specification.  Recent  work  by  Horning  (Horning  1S74a)  and 
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Gannon  (Gannon  1974)  has  emphasized  the  importance  of  useful 
redundancy.  A  system  with  an  implementation  and  an 
algebraic  specification  for  all  abstract  types  would  have  a 
tremendous  amount  of  such  redundancy  at  its  disposal.  An 
algebraic  specification  might*  for  example*  serve  as  the 
basis  of  an  acceptance  test  in  a  system  that  incorporates 
the  recovery  block  scheme  outlined  in  (Horning  1974b) . 


5 .  Conclusions 


In 

the 

above  discussion  I  have 

stressed 

the 

contributions 

that  the  dyadic 

specification 

technique 

may 

make 

towards 

increasing  the 

reliability 

of  software. 

I 

believe  that  this  specification  technique  may  also  play  a 
significant  role  in  increasing  one's  ability  to  have 
confidence  in  the  reliability  of  software.  This  would  be  an 
extremely  important  contribution.  A  program's  real  worth  is 
clearly  diminished  in  proportion  to  the  amount  invested  in 
procedures  to  monitor  its  performance.  And  a  program  whose 
output  is  not  believed*  is  of  little  use  —  regardless  of 
how  well  it  is  actually  performing. 

The  dyadic  specification  technique's  contribution  to  the 
enhancement  of  proof  and  test  procedures  should  enable  one 
to  have  a  greater  confidence  in  the  ^correctness"  of 
software.  This  increased  confidence  in  the  "correctness98  of 
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modules  should  in  turn  serve  to  mitigate  the  need  for  the 
introduction  of  redundant  modules  intended  to  enhance 
" reliability. ” 

The  Cassandra  syndrome  may  be  rooted  in  either  a  fear 
that  the  software  does  not  meet  the  specification  or  in 
qualms  about  the  correctness  of  the  specification  itself. 
For  the  reasons  outlined  above,  the  dyadic  specification 
technique  should  serve  to  quiet  fears  about  the  correctness 
of  an  implementation.  Qualms  about  a  specification's 
aptness  should  be  substantially  reduced  by  an  increase  in 
the  perspicuity  and  precision  of  specifications. 
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7 .  Appendix  J, 


7.1.  The  Meaning  of  Suf ficiently-Co mplete 

> 

In  this  work  I  found  it  convenient  to  focus  my  attention 
on  those  operations  whose  ranges  are  homogenous  sets  of 
single  objects.  (It  can  be  easily  shown  that  this  is  not  a 
significant  restriction.)  Thus,  for  example,  my 
axiomatization  of  type  STACK  includes  a  TOP  operation  that 
maps  a  STACK  into  an  ITEM  and  a  POP  operation  that 
transforms  a  STACK  into  a  STACK,  rather  than  a  POP  that 
takes  a  STACK  into  a  [ITEM  X  STACK].  This  restriction  leads 
to  a  relatively  obvious  partitioning  of  operations  into 
equivalence  classes  based  upon  their  ranges  and  domains: 

Let  T  be  the  set  of  all  values  of  the  type  being 

defined. 

FT  be  the  set  of  ail  operations  of  that  type. 

T®  be  the  set  of  all  values  of  a  type  other  than  that 
being  defined. 

With  respect  to  the  type  being  defined,  there  is  a 
partitioning  by  domain  and  range  of  the  operations  into  maps 
(from  T*  X  T«*  to  T9) ,  operators  (from  T*  X  T 8 *  to  T) ,  and 
constants  (from  0  to  T)  .  For  any  type  T,  I  shall  refer  to 
these  three  sets  as  mT ,  oT,  and  kT  respectively.  Between 
them,  the  constants  and  the  operators  generate  the  set  of 
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values  that  forms  T.  In  principle,  one  could  define  a  type 
for  which  there  were  no  maps.  Such  a  type,  however,  would 
be  singularly  uninteresting.  With  no  way  to  partition  the 
set  (no  maps  implies  no  predicates)  or  to  relate  members  of 
the  set  to  members  of  other  sets,  no  member  of  the  set  could 
be  distinguished  from  any  other.  That  is  to  say,  every 
value  of  the  type  would  be  equivalent  to  every  other  value 
of  the  type.  For  all  intents  and  purposes,  there  would  be 
only  one  value  of  that  type. 

Thus,  it  seems  that  the  significance  of  the  values  of 
objects  of  any  type  is  embedded  solely  in  the  effect  that 
these  values  have  when  they  appear  in  the  argument  lists  of 
maps  on  that  type.  This  observation  leads  directly  to  the 
following  development  of  the  notion  of  "suff iciently- 
complete. ” 

Notation:  Let  us  call  the  specification  of  the  ranges  and 
domains  of  the  operations  on  the  type  the  syntactic 
specification  (ss  for  short)  of  the  type. 

Definition:  The  range  type ,  rt ,  of  a  function  (operation) 
is  the  type  of  its  output. 

Definition :  The  domain  type ,  dt,  of  an  n-place  function  is 
an  n-tuple  (t1,...,tn)  in  which  each  ti,  1<i<n,  has  as  its 
value  the  type  of  the  ith  argument  of  the  function. 
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As  the  name  implies,  a  syntactic  specification  in  effect 
serves  as  a  grammar.  It  defines  the  manner  in  which  the 
newly  defined  type  may  be  used.  More  precisely: 

Definition :  The  language  over  a  syntactic  specification  of  a 
type  is  defined  constructively  as  follows: 

Let  L-1 (T)  be  a  set  of  free  variables,  {xl , x2, • . , 
each  of  which  may  assume  any  type. 

25  Let  L°  (T)  be  the  union  of  L”£  (?)  and  all  constants 
appearing  in  the  syntactic  specification  of  T. 

3)  For  i=0,1,2...  let  L  (T)  be  the  union  of  L  (T)  and 
the  set  of  all  terms  of  the  form  f  (c1,...,cn)  for  all  n- 
place  functions  occurring  in  ss  (T)  where  each  cj, 
is  a  member  of  L  (T)  and  the  n-tuple  (rt  (cl)  ,  •  •  • ,  rt  (cn) )  is 
equal  to  dt(f  ). 

s>  Each  L  (T)  is  called  the  i- level  language  set  of  T, 
and  L  (T)  (or,  more  simply,  L  (T) )  the  language  over  T,  Note 
that  for  any  term  contained  in  L  (T) ,  the  maximum  nesting  of 
functional  applications  is  of  depth  i. 

Intuitively,  L  (T)  defines  a  set  of  terms  that  may  appear 
in  the  body  of  a  program  within  which  the  type  is  defined. 
For  an  axiom  set  to  be  suff iciently-complete,  it  must  assign 
a  meaning  to  each  of  those  strings.  Recalling  the 
discussion  of  when  it  is  necessary  to  distinguish  one  object 
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from  another  of  the  same  type,  it  becomes  apparent  that  our 
concern  must  lie  with  those  sentences  in  L (T)  whose  range 
type  is  something  other  than  the  type  being  defined  and 
whose  domain  type  includes  as  one  of  its  components  the  type 
being  defined,  i.e.,  terms  dominated  by  maps.  Thus,  if  an 
axiom  set  for  a  type  is  to  be  sufficient! y-complete,  it  must 

define  a  mapping  from  all  such  sentences  onto  objects  of  a 

\ 

type  different  from  the  one  being  defined. 

The  set  of  interesting  sentences  over  a 
syntactic  specification  of  a  type  T,  I (T) ,  is  equal  to  the 
set: 

{  w  \  wSL  (T)  &  w  is  dominated  by  a  map  } 

Definition :  For  any  axiom  set  S  and  any  syntactic 
specification  of  a  type  T,  S  is  a  sufficiently -complete 
axiomatization  of  T  if  and  only  if  for  each  w  contained  in 
I  (T) ,  there  exists  a  theorem  derivable  from  S  such  that  the 
theorem  is  of  the  form  w=u,  where  u  6  T®  .  (S  is  consistent 
if  for  every  w@I(T)  there  exists  a  unique  u€T®  such  that 
there  exists  a  theorem,  derivable  from  S,  of  the  form  w=u.) 

It  can  be  shown  that  in  general  the  problem  of 
establishing  whether  or  not  a  set  of  axioms  is  suf f icient ly- 
complete  is  unsolvable.  However,  the  system  under 
development  need  not,  as  I  have  already  pointed  out,  be  able 
to  recognize  all  suff iciently-complete  axiomatizations.  My 
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concern  is  with  sufficient  conditions,  not  necessary  ones* 
From  the  user8s  point  of  view,  the  issue  is  not  so  much 
whether  or  not  an  axiomat izat ion  is  suf f iciently-complete, 
but  rather  it  is  can  the  system  he  is  using  recognize  it  as 
suf f iciently-complete . 

Definition:  Given  a  total  function  B  such  that  R(x)=1  only 
if  (but  not  if  and  only  if)  x  is  a  suf ficient ly-compiete 
axiom  set,  an  axiom  set  S  is  recognizably  stiff  ic lent  ly- 
complete  (r.s.c.)  with  respect  to  B  if  and  only  if  H { S>  =  1 . 


7.2.  A  Schema  for  Presenting  Axiomatizations 

At  this  point,  I  should  like  to  formalize  the  schema  to 
be  used  for  the  presentation  of  axiomatizations  of  type 
algebras. 

Each  axiomatization  is  to  consist  of  a  finite  set  of 
relations  of  the  form  LHS  =  RHS ,  where  ,,=  ”  has  its  natural 
interpretation.  I.e.,  P  true  implies  that  P  with  LHS 
replaced  by  RHS  is  also  true.  For  an  axiomatization  of  a 
type,  T,  the  number  of  possible  relations  will  be 
constrained  by  limiting  the  possible  LHS*s,  LHS  (T) ,  to  a 
finite  set.  This  bounding  of  the  set  of  left  hand  sides  is 
based  upon  the  assumption  (discussed  earlier)  that  the 
significance  of  the  values  of  any  type  is  embedded  solely  in 
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the  effect  that  these  values  have  when  they  appear  in  the 
argument  lists  of  maps.  Thus,  any  axiom  set  in  which  all 
such  effects  were  defined  would  be  suf f iciently-comple te. 
This  train  of  thought  led  me  to  believe  that  one  could  limit 
the  set  LHS(T)  to  those  terms  generated  by  assigning  free 
variables  to  the  arguments  of  each  operator  and  permuting 
these  and  the  constants  of  the  type  through  those  positions 
in  the  argument  list  of  each  map  where  objects  of  type  T  may 
appear.  For  example,  applying  this  technique  to  the 
operations  I  have  defined  on  natural  numbers  (sea  Appendix 
2)  would  yield  the  left  hand  sides: 

?ZERO?  (ZERO) 

?ZERO?  (SUCC(X)  ) 

7EQUAL? (ZERO, ZERO) 

?  EQUAL? (ZERO, SUCC (x) ) 

?EQUAL?(SUCC(x)  ,  ZERO) 

7EQUAL?  (SUCC  (x)  ,SUCC(y)) 

Though  a  set  of  left  hand  sides  derived  via  the  above 
algorithm  should,  in  all  cases,  prove  sufficient,  it  may 
often  also  prove  to  be  inconvenient.  Consider  adding  the 
binary  operators  ADD  and  MULTIPLY  to  our  definition  of  type 
NATURAL  NUMBER.  Application  of  the  above  algorithm  leads  to 
an  axiom  set  containing  twenty  axioms.  On  the  other  hand, 
if  we  choose  to  implicitly  define  the  effect  that  ADD  and 
MULTIPLY  have  when  they  occur  as  arguments  to  maps,  by 
providing  axioms  that  relate  ADD  and  MULTIPLY  to  SUCC,  e.g.. 
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ADD(SOCC(x)  *S0CC(y) )  =  SUCC  (STJCC  (ADD  (x*  y)  ) )  ,  we  can  reduce 
the  number  of  axioms  needed  to  fourteen*  Thus,  it  appears 
that  it  is  sometimes  convenient  to  generate  left  hand  sides 
in  which  operators  occur  at  the  outermost  level.  It  seems* 
however*  that  the  level  of  nesting  present  in  the  left  hand 
side  may  still  be  limited  to  two* 

In  light  of  the  above  discussion*  I  have  elected  to 
limit  to  two  the  depth  to  which  functions  may  be  nested  in 
left  hand  sides  of  axioms*  Thus*  the  set  LHS (T)  of  left 
hand  sides  is  contained  in  L2  (T)  -  (T) .  A  more  detailed 
discussion  of  which  members  of  this  set  are  likely  to  prove 
convenient  will  be  contained  in  (Guttag  1975).  Its  members 
are  to  be  interpreted  in  the  natural  way*  i.e . *  ADD  (x  *y ) 
refers  to  the  value  that  results  when  the  operation  ADD  is 
applied  to  the  arguments  x  and  y. 

In  contrast  to  LH S  (T) *  the  set  RHS  (T)  is  infinite.  For 
any  LHSi(T)  the  set  of  possible  RHSi  (T)  0 s  is  recursively 
defined  as  follows: 

a  i  If  w  €  (L  (T)  union  L(T®)5  where  TB  is  any  type  that 
has  already  been  defined*  and  all  free  variables  appearing 
in  w  appear  in  LHSi(T)*  then  w  6  RHSi  (T)  . 

2 >  If  w  =  if  x  then  y  else  z  where  x*y*z  €  RHSi  (?)  and 
rt  (x)  =  boolean*  then  w  €  RHSi  (T)  . 
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3>  If  w  =  if  v  *=  x  then  y  else  z  where  x  €  cT;  v,y,z  e 


RHSi(T),  and  rt  (v)  =  T,  then  w  €  RHSi  (T)  • 

The  meaning  of  the  if  then  else  construct  is  the  natural 
one:  LHS  =  if  x  then  y  else  z  means  that  ?  5  x  implies  P 
with  LHS  replaced  by  y,  while  P  &  -^x  implies  ?  with  LHS 
replaced  by  z.  The  "*="  operator  (=  in  some  earlier  papers 
of  mine)  has  a  rather  less  obvious  interpretation.  In 
addition  to  its  two  explicit  arguments,  it  implicitly 
accepts  a  third  argument:  the  set,  EELS,  of  all  relations 
in  the  axiomatization  of  type  T.  Loosely  stated,  A*=B  may 
be  said  to  mean:  "if  A  can  be  reduced  to  B  through  the 
application  of  the  relations  defined  on  the  type  T,  then 
true,  otherwise  false,"  In  the  most  general  case,  this 
guestion  is  not  always  decidable.  If  one  is  willing  to 
restrict  the  nature  of  the  possible  reductions  and  settle 
for  a  slightly  less  powerful  *=  operator,  however,  one  can 
reduce  the  guestion  to  a  solvable  one. 

Having  thus  restricted  the  manner  in  which  type 
definitions  may  be  supplied,  it  becomes  necessary  to  address 
the  guestion  of  whether  or  not  the  schema  defined  is 
sufficient  to  specify  any  type  that  one  might  wish  to 
define.  That  is  to  say,  does  the  class  of  algebras  that  can 
be  defined  via  the  mechanisms  provided  include  all  of  those 
algebras  that  might  prove  useful  to  a  programmer? 

Clearly,  in  discussing  the  inherent  power  of  this 
schema,  it  is  appropriate  to  eliminate  the  use  of  operations 


76 


defined  on  other  types.  Me  thus  consider  a  slightly 
restricted  definition  of  RHS(T)  in  which  those  terms 
contained  in  L(T®)  are  eliminated.  Then,  the  class  of  types 
that  can  be  defined  is  equivalent  to  the  class  of  functions 
that  can  be  defined  by  stating  their  relationships  to  one 
another  in  terms  of  the  primitive  operations  =  ,  *=,  and  if 
then  else. 

Theorem  J:  Any  algebraic  system  all  of  whose  operations  are 
partial  computable  functions  may  be  axiomatically  defined 
using  only  the  primitives  (as  defined  above)  =  ,  *=,  and  if 
then  else. 

Proof : 

1 >  Below,  is  an  axiomatization  of  a  generalized  Post 
tag  system  with  an  alphabet  equal  to  {0,1}  and  a  deletion 
number  of  two.  It  has  been  specified  in  terms  of  the  three 
primitives  referred  to  in  the  theorem. 
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EMPTY  : 
ZERO: 
ONE: 
APPEND: 
ERASE1 : 
7ZERQ? : 
TONE?: 
STEP: 
PLAY  : 


0  ->  String 
0  •>  String 

0  ->  String 

String  X  String  ->  String 
String  ->  String 
String  ->  Boolean 
String  ->  Boolean 

String  X  String  X  String  ->  String 
String  X  String  X  String  ->  String 


Axioms: 

ERASE1 (EMPTY)  =  EMPTY 
ERASE1  (ZERO)  =  EMPTY 
ERASE1  (ONE)  =  EMPTY 
ERASE 1  (APPEND (si *s 2)  )  = 

if  si  *=  EMPTY 

then  ERASE1 (s2) 

else  APPEND  (ERASE  1  (si)  rs2) 

?  ZERO?  (EMPTY)  =  false 
? ZERO?  (ZERO)  =  true 
?ZERO?  (ONE)  =  false 
?ZERO (APPEND (s1ps2) )  = 
if  si  *=  EMPTY 

then  ?ZER0?(s2) 
else  ?ZERO?(s1) 

?ONE?  (EMPTY)  =  false 
?ONE?  (ZERO)  =  false 
? ONE?  (ONE)  =  true 
?ONE? (APPEND (si ,s2)  )  = 
if  si  *=  EMPTY 
then  ?ONE?  (s2) 
else  ?ONE?  fsl) 

STEP  (si ,s2,s3)  = 
if  ?ZERO?  (si) 

then  APPEND (ERASE1 (ERASE1 (si)  )  ,s2) 
else  if  ?0N  E?  ( s  1) 

then  APPEND  (ERASE1  (ERASE1  (si)  )  ,s3) 
else  error 


PLAY (s1ys2*s3)  = 

if  ERASE1  (ERASE1  (si) )  *=  EMPTY 

then  si 

else  APPEND (si ,PLAY (STEP (si ,s2,s3)  „s2,s3) } 
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25  The  PLAY  operation  in  this  algebra  can  be  thought  of 
as  a  parametric  operation.  If  one  wished  to  define  a 
particular  tag  system*  rather  than  the  universal  one  I  have 
defined,  one  would  merely  have  to  replace  s2  and  s3  with 
specific  strings  generated  from  the  primitives  ZERO ,  ONE, 
and  APPEND. 

3*  It  is  thus  apparent  that  the  given  schema  for 
specifying  type  algebras  is  sufficient  to  define  any  Post 
tag  system  with  a  deletion  number  of  two  and  an  alphabet  of 
cardinality  two. 

Hence*  any  partial  function. 

s>  Hence,  by  combining  specific  Post  systems,  any 
algebra  all  of  whose  operations  are  partial  functions. 

Thus  we  see  that  the  schema  provided  for  type 
specifications  will,  in  all  instances,  prove  to  be 
sufficiently  powerful.  In  point  of  fact,  it  is  probably  too 
powerful.  While  it  is  true  that  on  rare  occasions  one  may 
wish  to  write  a  non- terminating  program,  in  most  cases  non¬ 
termination  is  indicative  of  an  error.  For  this  reason,  it 
seems  that  to  permit  the  specification  of  possibly  non¬ 
terminating  operations  (e.g.,  PLAY  in  the  axiomatization 
above)  is  likely  to  produce  more  harm  than  good.  It 
therefore  seems  useful  to  devise  restrictions  on  the  schema 
for  building  axioms  that  will  ensure  that  only  total 
functions  are  specified.  This  isn®t  to  say  that  any  input 
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to  an  operation  must  be  deemed  acceptable,  e.g.,  PRED  (ZERO) 
over  the  natural  numbers,  but  merely  that  the  operation 
should  never  fail  to  converge.  In  the  case  of  an 
unacceptable  input  it  could,  for  example,  return  the 
distinguished  value  “'error,**  as  in  some  of  the  examples  in 
Appendix  2. 

It  is,  of  course,  impossible  to  derive  a  set  of 
necessary  ana  sufficient  restrictions.  To  do  so  would  be  to 
solve  the  halting  problem.  So  we  investigate  sufficient 
condi tions. 

\ 

Theorem  2:  Any  conditions  that  are  sufficient  to  ensure 
sufficient-completeness  will  ensure  that  all  operations  are 
total . 

Proof : 

1 >  S  suf f iciently-complete  implies  (by  definition)  that 
for  all  w  €  I  (ss)  there  exists  a  reduction  to  u,  where  u  S 
T  • . 

2>  This  implies  that  for  all  w€I(T),  w  converges. 

3>  Now,  recall  that  two  terms,  tl  and  t2,  with 
rt  (t 1) =rt  (t2) =type  of  interest,  are  distinct  if  and  only  if 
there  exists  an  n-place  function,  f,  contained  in  the  maps 
of  T  such  that  f  (cl, . . .t 1. . • ,cn-1)  *  f (cl , . . .t2. • . , cn-  1)  and 
both  f (cl, • . .tl . . . # cn- 1)  and  f {cl , . . .t2. . ., cn-1 )  are 
contained  in  1 (T) . 
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♦>  From  the  definition  of  I  (T)  it  is  clear  that  both 
f  (d,...t1...  ,011-1}  and  f  (cl , . . . t2.  „ .  ,cn- 1)  are  contained  in 
I  (T)  . 

5>  Now,  2)  implies  that  both  f  (cl , .  .  .  1 1 . .  . ,  cn- 1)  and 
f  (cl , . . .t2. . . ,cn- 1)  converge, 

3)  implies  that  they  have  different  values.  This 
implies  that  both  tl  and  t2  are  inspected  by  f. 

7>  Therefore  both  tl  and  t2  converge,  i.e.,  have  values. 
Thus,  since  they  can  be  any  term  contained  in  L  (T) -  I  (T) , 
all  operators  and  constants  defined  for  T  must  be  total. 

Therefore,  since  2)  clearly  implies  that  ail  maps 
are  total,  suff iciently-complete  implies  that  all  functions 
are  total. 

Corollary  (trivial):  S  r.s.c.  (with  respect  to  any  R)  , 
implies  that  all  operations  axiomatized  by  S  are  total. 

It  is  important  that  r.s.c.  implies  that  all  operations 
defined  for  the  type  are  total.  From  the  user's  point  of 
view,  it  means  that  when  the  system  tells  him  that  his 
axiomatization  is  r.s.c.,  he  not  only  learns  something  about 
the  axiomatization,  but  he  also  learns  (or  is  reassured 
about)  something  about  the  operations  that  have  been 
axiomatized.  Theorem  2  also  serves  to  highlight  the 
difficulty  involved  in  checking  the  sufficient-completeness 
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of  an  axiomat izat ion.  It  leads  us  to  theorem  3  which  states 
that  there  can  be  no  set  of  conditions  that  one  can  test  for 
that  are  sufficient  to  ensure  sufficient -completeness  and 
2>  general  enough  to  guarantee  that  there  exists  an  r.s.c. 
axiom atization  of  any  type  that  one  might  wish  to  define. 

Theorem  3:  There  does  not  exist  a  decision  procedure  for 
determining  sufficient-completeness  such  that  for  all 
algebras  composed  of  total  functions,  there  exist  r.s.c. 
axiomatizations. 

Proof : 

l>  Assume  that  theorem  3  is  false. 

2>  The  set  of  all  functions  is  known  to  be  r.e. 

35  Clearly,  then,  the  set  of  all  sets  of  functions  is 

r.e. 


Thus  the  set  of  all  syntactic  specifications  is  r.e. 

5>  For  any  syntactic  specification,  the  set  of 
axiomatizations  (according  to  the  schema  I  have  presented) 
is  r.e. 

From  1)  and  5),  rhe  set  of  all  r.s.c.  axiomatizations 

is  r.  e. 

7 3  The  set  of  all  functions  included  in  such  an 
axiomatization  is  recursive. 


82 


Thus,  from  7)  and  6),  the  set  of  all  functions 
contained  in  an  r.s.c.  axiomatizations  is  r.e.  Call  this 
set  F. 

9  >  Theorem  2  implies  that  all  functions  contained  in  F 
are  total, 

10)  -j)  implies  that  all  total  functions  are  contained  in 

F. 

ai)  9)  and  10)  imply  that  the  set  F  is  the  set  of  all 
total  functions,  8)  that  this  set  is  r,e. 

12)  But  this  is  known  not  to  be  the  case,  hence  the 
assumption  of  1)  must  be  incorrect. 

The  ramifications  of  this  are  not  so  unfortunate  as  they 
may  at  first  appear  to  be.  For  though  one  cannot  construct 
a  decision  procedure  general  enough  to  encompass  all  types 
that  one  might  wish  to  define,  it  does  seem  to  be  possible 
to  construct  a  decision  procedure  that  will  encompass 
arbitrarily  many. 

Theorem  4:  For  each  algebra  composed  of  total  functions, 

there  exists  a  decision  procedure  for  determining 
sufficient-completeness  such  that  there  exists  an  r.s.c. 
axiomatization  for  that  algebra. 

Though  one  could  conceivably  construct  arbitrarily 
complex  conditions  that  would  guarantee  sufficient 
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completeness,  and  thus  encompass  arbitrarily  large  classes 
of  total  functions,  it  seems  unlikely  that  this  would  prove 
convenient.  My  experience  with  programming  has  led  me  to 
believe  that  the  occasions  where  one  has  need  of  a  non¬ 
primitive  recursive  function  are  very  rare  indeed.  It  thus 
seems  that  if  one  were  to  build  a  system  that  incorporated  a 
decision  procedure  such  that  for  all  primitive  recursive 
functions  there  exist  recognizably  suf f iciently-complete 
axiomatizations,  one  would  have  a  system  that  would  be 
sufficient  for  almost  all  applications.  I  have  developed  a 
set  of  restrictions  on  the  schema  for  supplying 
axiomatizations  of  types,  around  which  such  a  decision 
procedure  can  be  built.  A  discussion  of  these  restrictions 
and  this  procedure  will  be  contained  in  (Guttag  1975). 
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8 .  Appendix  2 


Natural  Numbers 


Operations : 

ZERO:  0  ->  Natural  Number 

SUCC:  Natural  Number  ->  Natural  Number 

?ZERO?:  Natural  Number  ->  Boolean 

?EQOAL?:  Natural  Number  X  Natural  Number  - 


Axioms : 

?ZERO?  (ZERO)  =  true 
?  ZERO?  (SUCC (x) )  =  false 
7EQ0AL? (ZERO, ZERO)  =  true 
?EQUAL? (ZERO, SUCC(x)  )  =  false 
7EQUAL? (SUCC (x) , ZERO)  =  false 
? EQUAL?  (SUCC  (x)  *SUCC  (y)  )  =  ?EQUAL?(x,y) 


Integers 


Operations : 

ZERO:  0  ->  Integer 

SUCC:  Integer  ->  Integer 

PRED:  Integer  ->  Integer 

ADD:  Integer  X  Integer  ->  Integer 

SUB:  Integer  X  Integer  ->  Integer 

?ZERO?:  Integer  ->  Boolean 


SUCC  (PRED  (X)  )  =  PRED  (SUCC  (x)  }  =  X 

ADD ( ZERO  t x)  =  x 

ADD (SUCC (x)  , y)  =  SUCC (ADD (x, y ) ) 
ADD  (PRED  (x)  ,  y)  =  PRED  (ADD  (x,  y) ) 
SUB {x, ZERO)  =  X 

SUB (xe  SUCC  (y)  )  =  SUB(PRED  (x)  ,  y) 
SUB  (x,  PRED  (y)  )  =  SUB(  SUCC  (x)  ,  y) 

?  ZERO?  (x)  = 

if  X  *=  ZERO 
then  true 
else  false 


Boolean 
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Queue 


Operations : 


EMPTY: 
ADD: 
REMOVE : 
FRONT: 

? EMPTY?: 


0  ->  Queue 

Queue  X  Item  ->  Queue 
Queue  ->  Queue 
Queue  ->  Item 
Queue  ->  Boolean 


Axioms: 

?EMPTY? (EMPTY)  =  true 
? EMPTY?  (ADD  (x,y) )  =  false 
FRONT  (EMPTY)  =  error 
FRONT (ADD (x,v) )  = 
if  ?EMPTY  ?  (x) 
then  y 

else  FRONT (x) 

REMOVE (EMPTY)  =  error 
REMOVE  (ADD  (x,  y) )  = 

if  ?EMPTY?  (x) 
then  EMPTY 

else  ADD(REMOVE (x) ^y) 


Vector 


Operations : 


EMPTY:  0  ->  Vector 

ASSIGN:  Vector  X  Index  X  Item  ->  Vector 

READ:  Vector  X  Index  ->  Item 

7EMPTY? :  Vector  ->  Boolean 


Axioms : 

7EMPTY? (EMPTY)  =  true 
? EMPTY? (ASSIGN (x,  y ,  z)  )  =  false 
READ  (EMPTY, w)  =  error 
READ  (ASSIGN  (x*  v,  z)  ,w)  = 

if  y=w  /*as  defined  for  the  index  type*/ 
then  z 

else  READ(x,w) 
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Chessboard 


Operations : 

XNIT : 

MOVE: 

KSIDE_CASTLE : 

QSIDE_CASTLE: 

PROMOTE: 

EN_PASSANT: 

OCCUPANT: 


0  ->  Board 
Board  X  Coord 
Board  X  Coord 
Board  X  Coord 
Board  X  Coord 
Board  X  Coord 
Board  X  Coord 


X  Coord  ->  Board 
X  Coord  ->  Board 
X  Coord  ->  Board 
X  Piece  ->  Board 
->  Board 
->  {Piece,  emptjl 


Axioms: 

OCCUPANT  (XNXT,  A1)  =  white  rook 


OCCUPANT  {MOVE  (X,y,z)  ,  u)  = 
if  u=z 

then  OCCUPANT (x,  y) 
else  if  u=y 

then  empty 

Use  OCCUPANT  <x,u) 

OCCUPANT  (EN_PASSANT  (x,y)  ,z)  = 
if  z=y 

then  empty 

else  OCCUPANT  (x,z) 

OCCUPANT (KSIDE_CASTLE  (x,y,z)  , u)  = 
if  u=y  V  u=z 
then  empty 

else  if  RANK  (u)  =RANK  (z)  &  FILE  (u)  =G 
then  OCCUPANT (x,z) 

else  if  RANK  (n)  =RANK  (y)  S  FILE  (n)  =F 
then  OCCUPANT  (x,y) 
else  OCCUPANT  (x,ti) 

OCCUPANT (QSXDE_CASTLE (xfy ,z)  , u)  = 
if  u=z  V  u=y 
then  empty 

else  if  RANK  (u)=RANK  (y)  8  FXLE(u5=C 

. then  OCCUPANT (x,z) 

else  if  RANK  fu)  =RANK(y)  §  FILE  (u)  =  D 
then  OCCUPANT (x,y) 
else  OCCUPANT  (x,u) 

OCCUPANT (PROMOTE (x,  y,  z) , u)  = 

if  U=y 

then  z 

else  OCCUPANT  (x,u) 
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Mathematical  Semantics  as  a  Complementary  Definition 
for  Axiomatically  Defined  Programming  Language  Constructs 

James  E.  Donahue 
Department  of  Computer  Science 
University  of  Toronto 
Toronto,  Ontario  CANADA 


Abstract:  Axiomatic  definitions  of  programming  language 

semantics  have  been  developed  for  a  large  number  of 
constructs  and  have  been  shown  useful  in  a  wide 
variety  of  program  proving  settings.  However* 

axiomatic  definitions  do  not  provide  a  useful 
implementation  model  and  may  hide  undesirable 
semantic  aspects  of  a  construct.  This  paper 
discusses  the  use  of  mathematical  semantics  as  an 
approach  to  providing  complementary  definitions  of 
constructs  defined  using  the  axiomatic  approach.  An 
example  of  a  complementary  definition  is  given  using 
the  two  approaches  and  the  question  of  the 

consistency  of  the  definitions  given  is  explored  in 
detail.  As  the  example  illustrates*  the  use  of 
mathematical  definitions  provides  a  useful 
complement  to  axiomatic  definitions. 
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1  •  Introduction 


One  of  the  major  areas  of  research  in  the  effort  to 
produce  more  reliable  software  is  the  development  of 
techniques  to  formally  prove  that  a  program  has  the  logical 
properties  desired  by  its  author.  The  basis  for  any 
deductive  system  used  to  prove  properties  of  programs  is  a 
definition  of  the  semantics  of  the  programming  language 
used,  stating  the  logical  properties  of  the  constructs  of 
the  language. 

The  most  successful  work  in  this  area  has  been  Hoare* s 
axiomatic  approach  to  semantic  definition  [1969a,  1969b, 
1971a,  1972b].  Axiomatic  definitions  have  been  developed 
for  a  large  number  of  constructs  present  in  different 
languages  [ Hoare  1971a,  1972a,  Clint  and  Hoare  1972,  Clint 
1973,  Lauer  1971,  Igarishi,  London,  and  Lucknam  1973]  and 
have  been  successfully  used  to  prove  properties  of  a  number 
of  interesting  programs.  This  paper  discusses  the  use  of 
"mathematical"  semantics  to  provide  complementary 
definitions  of  axiomatically  defined  programming  language 
constructs.  The  definitions  are  considered  to  be 
complementary  because  the  relation  between  the  two 
definitions  can  be  naturally  explained  by  considering  either 
as  the  primary  definition.  If  the  axiomatic  definition  is 
taken  as  the  primary  definition  of  a  construct,  then  the 
mathematical  definition  can  be  viewed  as  a  more  procedural 
explication  of  the  construct  (making  it  suitable  as  a  guide 
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to  implementors)  .  Or  if  the  mathematical  definition  is 
taken  as  the  primary  definition  of  the  construct#  then  the 
axiomatic  definition  can  be  considered  a  correct  statement 
of  the  logical  properties  of  a  construct  if  it  is  valid  with 
respect  to  the  mathematical  definition  given.  A  major  theme 
of  this  paper  will  be  the  advantages  of  the  use  of 
complementary  definitions  of  programming  language  semantics 
using  these  two  approaches. 

The  paper  is  organized  as  follows.  Section  2  discusses 
the  idea  of  complementary  definitions  of  programming 
language  semantics  in  more  detail.  Section  3  gives  an 
example  of  complementary  mathematical  and  axiomatic 
definitions  using  a  simple  subset  of  Algol.  The  fourth 
section  gives  a  proof  of  consistency  of  the  definitions.  In 
the  fifth  section  we  discuss  the  general  problem  of  relating 
axiomatic  definitions  to  languages  with  a  richer  ^domain  of 
discourse”  than  is  expressible  using  the  axiomatic  approach. 
Section  6  draws  some  conclusions  about  the  usefulness  of 
complementary  definitions  for  more  complex  languages. 

2.  Complementary  definitions  of  programming  language 

semantics 

The  idea  of  complementary  definitions  of  programming 
language  semantics  was  first  suggested  by  Hoare  and  Lauer 
[1973].  The  rationale  for  providing  complementary 
definitions  is  based  on  the  belief  that  no  single  semantic 


91 


definition  technique  can  adequately  meet  the  widely 
disparate  needs  of  language  designers,  implementors,  and 
users.  This  belief  is  certainly  true  for  axiomatic 
definitions.  The  implicit  nature  of  the  specification  of 
computations  in  the  axiomatic  approach  has  advantages  for 
users  who  wish  to  prove  properties  of  their  programs. 
However,  the  implicitness  of  the  specification  is  clearly  a 
disadvantage  to  implementors,  who  desire  a  model  making  the 
computations  invoked  by  a  construct  more  explicit. 

Additionally,  the  development  of  multiple  definitions  of 
a  construct  may  serve  as  a  useful  check  to  guarantee  that  a 
particular  definition  does  not  hide  undesirable  semantic 
aspects  of  a  construct.  The  necessity  for  such  a  check 
seems  particularly  important  in  the  case  of  axiomatic 
definitions,  because  of  the  implicit  nature  of  the  approach. 
Section  3  gives  an  example,  the  proof  rules  published  for 
PASCAL  procedures  [Hoare  and  Wirth  1972],  of  a  seemingly 
valid  axiomatic  definition  that  does  not  correspond  with  our 
intuitive  notion  of  the  meaning  of  the  construct  being 
defined . 

We  argue  that  the  axiomatic  and  mathematical  approaches 
together  provide  a  useful  basis  for  complementary 
definitions.  The  axiomatic  approach  has  been  successfully 
employed  in  the  development  of  proofs  of  program  properties 
in  a  number  of  settings.  In  particular,  axiomatic 
definitions  have  been  used  in: 
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1.  hand-generated  proofs  of  program  properties  [Hoare 
1971b  ], 

2.  proof-checking  systems  [ Lauer  1971],  and 

3.  mechanical  program  verifiers  [Igarishi,  London?  and 
Luckham  1973]. 

The  mathematical  approach  has  been  shown  to  be  useful  in  the 
design  of  languages  [  Tennent  1973]  and  the  development  of 
implementations  [Milne  1974].  Thus?  definitions  of 
languages  using  both  techniques  should  give  a  formal 
semantics  that  would  effectively  meet  the  needs  of  a  fairly 
wide  audience. 

In  addition  to  a  set  of  definitions,  each  using  a 
different  method,  a  complementary  definition  must  also 
provide  some  assurance  that  the  definitions  given  do,  in 
fact,  define  the  same  language.  Thus  a  complementary 
definition  of  a  programming  language  must  include  both  a  set 
of  definitions  using  various  approaches  and  a  proof  of  the 
consistency  of  the  definitions.  Some  techniques  for  proving 
that  mathematical  and  axiomatic  definitions  are  consistent 
will  be  discussed  and  demonstrated  in  Section  4. 

Along  with  benefits  to  both  implementor  and  user,  the 
process  of  developing  and  proving  the  consistency  of 
complementary  definitions  may  provide  important  benefits  in 
the  language  design  process.  As  PL/I  illustrates?  the 
ability  to  produce  a  formal  semantic  definition  of  a 
language  is  certainly  no  guarantee  that  the  language  is 
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well- designed .  However,  the  requirement  of  providing 

specialized  definitions  for  use  by  various  audiences  and 
proving  their  consistency  may  have  a  beneficial  effect  on 
language  size  and  complexity.  And  reduction  of  the  size  and 
complexity  of  the  languages  used  to  write  programs  will 
almost  certainly  enhance  the  reliability  of  the  programs 
produced . 

3 .  An  example  of  complementary  definitions 
3.1  The  example  language 

As  an  example  of  the  use  of  complementary  definitions, 
we  will  consider  a  simple  Algol-like  programming  language 
consisting  of  assigments,  conditionals,  iterations,  and 
blocks.  The  syntax  of  the  language  (ignoring  ambiguities) 
is  the  following: 

<stmt>  ::=  <id>:=<exp> 

|  <stmt>  ;  <stmt> 

|  if  <exp>  then  <stmt>  else  <stmt>  end 
i  while  <exp>  do  <stmt>  end 
j  begin  new  <id>;  <stmt>  end 
|  begin  <stmt>  end 

To  shorten  the  length  of  the  presentation,  the  syntax  of 
expressions  and  identifiers  will  not  be  given.  The 
intuitive  meaning  of  each  construct  should  be  clear;  we  now 
present  the  formal  semantics  of  the  constructs  in  both 
axiomatic  and  mathematical  terms. 
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3.2  Axiomatic  gem an tics  of  the  language 

Axiomatic  semantics  give  the  meaning  of  a  construct  in  a 
programming  language  as  a  relation  between  propositional 
expressions.  The  class  of  propositional  expressions  is 
defined  as  follows: 

1.  a  term  is  an  expression  in  the  source  language?  and 

2.  a  propositional  expression  (or  assertion)  is  a  well- 
formed  logical  expression  constructed  from  terms 
using  logical  connectives  and  quantifiers  according 
to  the  usual  rules  of  predicate  calculus. 

Statements  in  the  language  are  identified  with  relations  of 
propositional  expressions  where: 

1.  the  atomic  statements  of  the  language  are 
characterized  by  axioms  or  axiom  schemata?  and 

2.  compound  statements  are  characterized  by  rules  of 
inference  with  one  or  more  premises. 

An  axiom  in  the  system  is  written 

P  {Q}R 

where  P  and  R  are  propositional  expressions  and  Q  is  a 
statement  of  the  language.  Intuitively?  this  can  be  read  as 
"if  the  assertion  P  is  true  prior  to  the  execution  of  Q  and 
the  execution  of  Q  terminates  normally?  then  R  is  true  after 
execution  of  Q."  A  rule  of  inference  has  one  of  two  forms: 

HI?...?  Hn 
H 

stating  that  whenever  HI?...?  Hn  are  true?  H  is  true,  or 
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Hi,...,  Hn  j-  Hn-M 
H 

stating  that  whenever  Hn+1  can  be  proven  from  HI,...,  Hn, 
then  H  is  true.  A  proof  of  the  conditional  correctness  of  a 
program  Q  with  respect  to  a  property  R  is  a  derivation  of 
P  {Q}  R  for  some  assertion  P. 

The  semantics  of  our  example  language  in  axiomatic  terms 
can  be  given  as  follows: 

RO  R  (e/x)  {x:=e}R 

where  R(e/x)  is  the  result  of  substituting  e  for  all 
free  occurrences  of  x  in  R. 

R1.1  P  {begin  end}P 

R1.2  P{Q1}S,  S  {begin  Q2;...;Qn  end}R 

P  {begin  Q1;Q2;...Qn  end}  R 

R2  PSb{Q1}R,  PS-»b  {Q2}  R 

P{if  b  then  Q1  else  Q2  end}  R 

R3  PSb{Q}P 

P  {while  b  do  Q  end}PS-*b 

R4  z£{?ree(P}  u  Free  (R)  u  Id(Q)},  ?  (z/x)  {Q}  R  (z/x) 

P  {begin  new  x;  Q  end} R 

where  Free (P)  denotes  the  free  variables  in  the 
assertion  P  and  Id(Q)  denotes  the  free  identifiers 
in  the  statement  Q. 

Although  axiomatic  definitions  provide  a  useful 
abstraction  of  the  computation  invoked  by  a  construct,  one 
can  ask  whether  in  all  cases  it  is  the  right  abstraction  of 
the  right  computation.  As  an  example  of  a  case  where  an 
axiomatic  definition  conflicts  with  our  intuitive  notion  of 
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the  meaning  of  a  construct,  consider  the  rule  for  PASCAL 
procedures  given  by  Hoare  and  Wirth[ 1972]. 

Consider  a  procedure  of  the  form 

procedure  p  (L)  ;  S 

where  L  is  a  valid  parameter  list  and  S  is  a  PASCAL 
statement  with  free  variables  y1,...,yn  which  are  changed 
within  S,  and  parameters  x1,...,xm  which  are  variable 
parameters  (i.e.,  subject  to  assignment)  by  s.  Now  given  an 
assertion 

P{S}Q 

about  the  procedure  body  s,  the  rule  given  by  Koare  and 
Wirth  asserts  that  we  may  deduce  the  existence  of  functions 
f  (i)  and  g  ( j)  such  that 

P=>Q  (f  (1)  (x,y)  /xl  .  ,f  (m)  (x,y)  /xm, g  (1)  (x ,y)  /y  1 , . . . , g  (n)  (x,y)  /yn)  . 
In  effect,  a  procedure  is  defined  as  a  concurrent  assignment 
which  maps  each  non-local  variable  and  variable  parameter 
from  its  initial  to  final  value.  The  rule  for  procedure 
calls  is 

P(f(1)  (x,y)  /xl , . . .  ,g  (n)  (x,y)  /yn)  {p(x)}P 
where  x1,...,xm  are  the  members  of  x  subject  to  assignment 
and  y1,...„yn  are  all  non-local  variables  subject  to  change. 

These  rules,  however,  conflict  with  the  normal  notions 
of  block  structure  in  Algol-like  languages  in  their 
treatment  of  non-local  variables.  For  example,  consider  the 
PASCAL  sequence 


97 


var  x :  integer; 
procedure  zerox; 

begin  x:=0  end 
procedure  newx; 

var  x:  integer; 
begin  x:  =  1;  zerox  end 

newx 

Using  the  rules  of  inference  given  above  we  can  derive  the 
following  inconsistency,  given  the  normal  interpretation  of 
block  structure* 


Since  our  intuition  suggests  that  the  call  of  zerox  from 
newx  should  not  change  the  value  of  x  within  newx,  we  should 
expect  to  be  able  to  derive 

true  {begin  x:  =  1;  zerox  end} x= 1 

for  the  body  of  the  procedure.  However,  the  rules  given 
above  do  not  produce  such  a  derivation. 


The  body  of  zerox  can  be  easily  shown  to  satisfy 

true  {x :  =0}  x=0 . 

Thus  the  particular  g  defining  the  effect  of  the  procedure 
is 

g (x)  =  0 

since 


true=>  (x=0)  (0/x)  . 

Now,  applying  the  procedure  call  rule  to  the  call  of  zerox 
within  newx,  we  have 

(x=1)  (0/x)  {zerox}  x=1 


or 


false  {zerox} x= 1 . 

Applying  the  rules  for  sequences  and  groups,  we  produce 
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falsefbegin  x:=1;  zerox  end} x= 1 . 

This  is  certainly  not  consistent  with  the  result  produced  by 
our  intuitive  understanding  of  the  meaning  of  the  previous 
sequence. 

Note  that  the  Revised  PASCAL  Report  [Wirth  1973]  defines 
the  meaning  of  procedures  informally  in  a  manner  consistent 
with  the  intuitive  notions  used  above.  This  inconsistency 
with  the  axiomatic  definition  can  be  viewed  in  either  of  two 
ways.  If  the  axiomatic  definition  is  taken  as  the  real 
meaning  of  PASCAL  procedures,  then  the  difference  between 
Algol  and  PASCAL  scope  rules  are  certainly  well-' hidden  from 
the  unsuspecting  user.  Or,  if  the  Revised  PASCAL  Report  is 
taken  as  correct,  then  the  axiomatic  definition  does  not 
correctly  abstract  the  properties  of  PASCAL  procedures. 

In  addition  to  hiding  important  semantic  properties, 
axiomatic  definitions  do  not  state  sufficiently  the 
properties  that  must  be  satisfied  by  an  implementation.  Any 
non- terminating  implementation  would  satisfy  the  axioms  used 
above  to  define  our  example  language.  Also,  the  definition 
given  above  uses  a  rather  limited  '* domain  of  discourse,58 
i.e.,  only  the  class  of  expressions  in  the  source  language. 
This  may  not  be  expressive  enough  to  define  adequately  some 
of  the  constructs  common  to  more  complex  languages.  The 
mathematical  definitions  given  in  the  next  section  both 
provide  an  explicit  statement  of  the  computations  involved 
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and  allow  the  possibility  of  using  a  richer  domain  of 
discourse. 

3 . 3  Mathematical  semantics  of  the  lan quaere 

The  goal  of  mathematical  semantics  is  to  associate 
directly  with  each  construct  of  the  programming  language  its 
meaning  as  a  function  or  relation  of  some  appropriate  type. 
The  particular  form  of  mathematical  semantics  used  in  the 
following  definition  will  make  use  of  the  lattice- theoretic 
approach  to  the  theory  of  computation  developed  by  Scott 
[  1970  ].  In  particular: 

1.  The  data  types  used  in  the  definition  will  all  be 
domains  in  the  Scott  sense  [1972].  Primitive 
domains  are  formed  by  adjoining  to  a  countable  set 
the  special  elements  b  (the  undefined  value)  and  t 
(the  inconsistent  or  overdetermined  value)  .  More 
complex  domains  will  be  defined  using  the  following 
operations: 

a.  The  disjoint  union  domain  D1+D2  is  defined 
by  adding  t  and  b  to  the  union  of  D1  and  D2. 

b.  the  Cartesian  product  domain  D1xD2  is 
composed  of  ordered  pairs  of  elements  from 
D 1  and  D2 . 

c.  the  domain  D1->D2  consists  of  all  continuous 
functions  [Scott  1972]  from  D1  to  D2. 

Also, 
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2.  The  functions  used  to  give  Meaning  to  the  constructs 
of  the  language  will  all  be  continuous  with  respect 
to  these  domains. 

The  choice  of  domains  used  here  to  define  meaning  is 
motivated  by  a  desire  to  define  mathematically  exactly  the 
language  that  was  defined  in  the  last  section.  Following 
the  usual  form  of  mathematical  def initions?  we  define  the 
meaning  of  a  statement  as  its  effect  on  an  abstract  store 
relative  to  an  environment  and  a  continuation.  However?  the 
data  type  of  each  of  these  domains  is  determined  by  the 
expressive  power  of  the  assertion  language  in  the  axiomatic 
definition . 

In  particular?  the  meaning  of  a  program  identifier  in 
assertions  is  limited  to  the  value  ” possessed'*  by  the 
identifier.  This  does  not  allow  the  possibility  of  a 
distinction  between  a  location  referred  to  by  a  variable  and 
the  value  stored  at  that  location.  Thus  our  choice  of  type 
for  environment  and  store  does  not  allow  for  identifiers 
signifying  locations  and  locations  (rather  than  identifiers) 
denoting  stored  values.  The  abstract  store  therefore 
becomes  a  ,fprogram  state*®  of  type 

State  =  Xd->?aiue 

for  the  -domains  Id  of  identifiers  and  falue  of  stored 
values?  and  the  environment  is  given  type 

Env  =  Xd->Dval 
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for  the  domain  Dval.  of  "denotable"  values.  In  our  model, 
the  domain  of  storable  values  does  not  allow  the  possibility 
of  stored  ''state  transformations.”  Thus  the  domain  Dval 
includes  the  values  of  "named”  state  transformations,  such 
as  the  meaning  given  to  statement  labels  and  procedure 
declarations.  Additionally,  Dval  may  include  function 
values,  although  the  domain  will  not  be  specified  in  detail 
in  this  paper. 

Also,  since  expression  evaluation  is  considered  to  be  an 
atomic  action  in  the  axiomatic  definition  (constructs  like 
Reynolds*  "escape"  operator  are  not  allowed) ,  "expression 
continuations”  are  not  used  in  the  definition.  Instead,  the 
meaning  of  expressions  will  be  given  by  a  function  of  type 


Me:Exp->[ Env->[ State->Eval ]  ] 


for  the  domain  Eval  of  expression  values.  Note  also  that 
this  choice  of  functionality  does  not  allow  expression 
evaluation  to  produce  a  state  change  as  a  side-effect.  As 
the  class  of  expressions  is  being  left  unspecified  in  our 
example  language.  Me  will  not  be  given. 

The  specifications  of  the  syntactic  and  semantic  domains 
and  the  meaning  function  Ms  for  statements  follows.  The 
syntactic  domains  include: 


Id 

Exp 


identifiers 

expressions 

assignments 

sequences 


Stmt  -  (Id  x  Exp) 

+  (Stmt  x  Stmt) 

♦  (Exp  x  Stmt  x  Stmt) 
«■  (Exp  x  Stmt) 

*  (Id  x  Stmt) 


conditionals 

iterations 

blocks 


102 


The  construct  "begin  <stmt>  end"  is  used  only  to  provide 
grouping  and  is  considered  merely  a  syntactic  extension  to 
the  basic  language. 

The  semantic  domains  are: 

Env  =  Id->Dval 
Dval 

Eval  =  Value 

Value  =  Bool  ♦  Undef  ♦  ... 

Bool  =  {b,  true,  false,  t} 

Undef  =  {u} 

State  =  Id->Value 
Cont  =  State->State 

and  the  meaning  functions  are: 

Ms: Stmt->[ Env->[  Cont->[  State->State ] ] ] 

Me :Exp->[ Env->[  State->Eval] ] 

Before  presenting  Ms,  a  comment  about  notation  is 
necessary.  To  improve  readability,  functions  will  be 
defined  using  a  syntax  borrowed  from  Algol68,  rather  than 
the  more  common  lambda-notation.  To  shorten  the  paper,  the 
relation  between  our  notation  and  lambda  expressions  is 
given  in  the  Appendix.  Also  a  number  of  other  notational 
conventions  and  commonly  used  functions  are  defined  in  the 
Appendix.  However,  the  definitions  given  below  can  be 
skimmed  to  get  the  flavour  of  mathematical  semantic 
definitions  before  reading  the  Appendix. 

The  meanings  of  the  constructs  of  the  language,  using 
the  mathematical  approach,  are: 

Ms  {begin  stmt  end}  =  Ms  {stmt} 


environments 
denotable  values 
expression  values 
storable  values 
Booleans 
undefined 
program  states 
statement  continuations 
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Ms  {id:  =exp}  = 

(Env  e ; Cont  c; State  s) State: 
let  v  =  Me  {exp}  "(e;  s) 
in 

if  v=b  then  b 
else  if  v=t  then  t 
else 

c(s{id/v  in  Value]) 

\ 

Ms{if  exp  then  stmtl  else  stmt2  end}  = 

(Env  e ; Cent  c ; State  s ) State : 
let  b  =  Me  {exp}  (e;  s)  \  Bool 
in 

(b->Ms  {stmt  1}  ,  Ms{stmt2})  (e;  c;  s) 

Ms  {stmtl;  stmt2}  = 

(Env  e ; Cont  c ; State  s ) State : 

Ms  {stmtl}  (e;  Ms  (stmt 2}  (e ;  c) ;  s) 

Ms  {while  exp  do  stmt  end}  = 

rec  (Env  e ;Cont  c : State  s) State: 
let  b  =  Me  {exp}  (e ;  s)  \ Bool 
in 

(b->Ms{stmt}  (e;  Ms  {while  exp  do  stmt  end}  (e;  c) )  ,  c)  (s) 

Ms {begin  new  id;  stmt  end}  = 

(Env  e ; Cont  c; State  s) State: 

Ms  {begin  stmt  end}  (e;  c«  (State  s® )  :  s'  [  id/s  {id}  ];  s[  id/u ]) 


The  only  unusual  part  of  the  definition  is  the  meaning 
given  to  variable  declarations.  Rather  than  using  the  state 
component  to  record  unused  locations  and  allocating  a  new 
location  for  each  declaration ,  the  meaning  given  to 
declarations  is  simply  to  hide  the  old  value  of  the  variable 
and  to  restore  this  value  after  execution  of  the  block.  In 
this  case?  it  seems  that  the  choice  of  domains  used  to  give 
the  definition  has  resulted  in  a  less  {9impiementation- 
oriented88  definition  of  meaning.  We  now  turn  to  the 
question  of  the  consistency  of  the  two  definitions. 
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4.  Consistency  of  the  definitions 

To  show  the  definitions  consistent,  we  give  a  meaning  to 
the  formulas  of  the  axiomatic  definition  in  terms  of  the 
mathematical  model.  The  intuitive  meaning  of  the  axioms 
given  in  the  previous  section  can  be  made  formal  as  follows. 

First  it  is  necessary  to  give  an  interpretation  to 
assertions  with  respect  to  the  domains  of  the  mathematical 
definition.  To  do  this,  we  define  an  interpretation 

function  I  of  functionality 

I : Assertion*->[  En v*->[  State*-> {true,  false}  ]]. 

Here  *->  is  used  rather  than  ->  to  indicate  that  I  need  not 
be  continuous.  I  is  given  as  follows: 

1 .  The  logical  connectives  of  the  assertion  are  given 
their  standard  interpretation, 

2.  If  t  is  a  term  in  an  assertion,  then: 

a.  If  t  is  a  Boolean  expression  (i,e«,  the  test  in 
a  conditional  or  iteration  statement) ,  then  if 
-•t  appears  in  the  assertion,  then 

I  {-*t}  (e;  s)  =  Me  £t}  (e;  s)  j  Bool  =  false. 
Otherwise, 

I{t}(e;  s)  =  Me{t}(e;  s)  i Bool  =  true. 

b.  Otherwise, 

I  {t}  (e;  s)  =  Me  {t}  (e;  s)  . 


In  the 

following. 

to  reduce  the 

amount 

of 

notation. 

I  {PI  (e ;  s) 

will  be 

abbreviated  as 

P(e; 

s) 

for  any 

propositional  expression  P, 


105 


Our  intuitive  meaning  given  in  the  previous  section  to  a 
formula  ?{Q}R  of  the  axiomatic  theory  can  be  translated  into 
a  formal  statement  relative  to  the  mathematical  definition 
in  the  following  manner.  The  analogue  to  our  informal 
notion  of  normal  termination  of  execution  of  a  statement  is 
the  application  of  the  normal  continuation  in  rhe 
mathematical  definition.  Thus  our  interpretation  of  P{Q}R 
is 

?e  ¥s[  P  (e ;  s)  =>[  Vs*[  ¥c  Ms  {Q}  (e;  c;  s)  =  c  (s* )  ]  =>R(e;  s«)  ]  ]. 


The  right-hand  side  of  the  implication  is  vacuous  in  two 


cases : 


2. 


all  possible  computations  apply  a  continuation  other 
than  the  normal  continuation.  This  would  happen  if, 
for  example,  a  goto  was  executed  to  a  label  not 
local  to  the  statement. 

the  computation  fails,  i.e.,  produces  t  or  b.  The 
following  lemma  is  easily  shown  by  a  contradiction 
argument. 

Lemma ;  If  for  all  c,  Ms{Q}  (e ;  c;  s)  =  t  (or  b)  , 
then  there  does  not  exist  an  s*  such  that 
for  all  c, 

Ms  (Q}  (e;  c;  s)  =  c(s’)  . 

Thus  our  interpretation  seems  to  capture  accurately  the 
notion  of  partial  correctness  implicit  in  the  axiomatic 
approach. 
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The  proofs  that  the  axioms  and  rules  of  inference  do*  in 
fact,  hold  in  the  given  mathematical  model  (i.  e. *  that  their 
interpretation  is  true)  are  relatively  straightforward  and 
will  not  be  given  here  for  each  statement.  The  proof  of  the 
rule  for  the  iteration  statement  uses  fixed  point  induction 
and  follows  closely  the  proof  given  in  [Hanna  and  Vuillemin 
1972].  The  guarantee  that  such  fixed  points  exist  and  can 
be  used  to  give  meaning  to  the  recursive  definitions  is  an 
important  aspect  of  the  use  of  the  Scott  theory.  The  most 
interesting  proof  is  of  the  rule  for  variable  declarations, 
which  we  present  here  as  an  example  of  the  techniques 
involved . 

Lemma:  Rule  4  of  the  axiomatic  definition  is  valid  for  the 

mathematical  definition  given. 

Proof:  Rule  4  is: 

R4  z^fFree  (P)  u  Free  (R)  u  ld(Q)}#  P  (z/x)  (Q) R  (z/x) 

P  {begin  new  x;  Q  end]  R 

where  Free (P)  denotes  the  free  variables  in  the 
assertion  P  and  Id  (Q)  denotes  the  free  identifiers 
in  the  statement  Q. 

We  assume  the  premise  P  (z/x)  {0}  R  (z/x)  and  we  want  to 
show 

¥e  ¥s[  P  (e ;  s)  => 

¥s*[¥c  Hs  {begin  new  x;  Q  end}  (e;  c;  s)  =  c  (s* )  => 

RCeT's® )  ]]. 

First,  for  any  state  s,  we  define  a  new  state, 
s<x;y>,  as 

s<x §  y >  =  (s{  y/s  (x)  ])  [  x/s  (y)  ] 
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for  any  identifiers  x  and  y.  s<x;y>  can  be  regarded 
as  swapping  x  and  y  in  s.  If  z  does  not  appear  free 
in  P,  then  it  is  clear  that 

P(z/x)  (e;  s<x;y>)  <=>  P  (z/x)  (e  ;  s<x ;  y>[  x/u  ])  <=>  P  (e;  s) 

for  any  e  and  s.  And  from  the  premise,  we  have 

(*)  P  (z/x)  (e ;  s<z;x>[x/u])  => 

¥s*[¥c  Ms  {begin  Q  end}  (e;  c;  s<z;x>[x/u])  = 
c  (s9)"  =>  R  (e ;  s1 )  ]• 

Now  consider  c  of  the  form 

c  =  c9*(s”)  : s”[  x/s<z;  x>  (x)  ] 

By  (*)  we  have 

(**)  P  (z/x)  (e;  s<z;x>[x/u])  => 

¥ s 9  [  ¥c  Ms  {begin  Q  end}  (e;  c*  •  (s")  :  sM[  x/s<z ;  x>  (x)  ];  s) 
(c 1  •  { s M)  :  s”[  x/s<z  ;x>  (x)  ]}  (se)  => 

H (z/x)  (e;  s8)  ] 

And, 

B(z/x)(e;  s')  <=>  R(z/x)(e;  s 1  [  x/s<z;  x>  (x)  ])  . 
Therefore,  from  (**)  and  the  definition  of 
Ms  {begin  new  x;Q  end}, 
we  can  derive 

(***)  P  (z/x)  (e;  s<z  ;  x>[  x/u  ])  => 

¥s*  ¥c  Ms{begin  new  x;Q  end}  (e;  c;  s< z ; x> ) =c ( s 8 ) => 
R (z/x)  (e;  s9)  . 

But  we  know  that  if 

Ms  {begin  new  x;Q  end}  (e;  c;  s)  =  c(s*) 

then 

s*  (z)  =  s(z)  since  z  not  in  Free  (Q)  and 

s9  (x)  =  s  (x)  since  the  continuation  restores  x. 

Thus  if 

Ms  {begin  new  x;  Q  end}  (e;  c;  s<z;x>)  =  c  ( s 1 )  ,  then 

Ms  {begin  new  x;  Q  end}  (e;  c;  s)  =  c(s9<z;x>). 
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And?  since  z  is  not  free  in  R  it  is  clear  that 
R(z/x)(e;  s®)  <=>  R  (e ;  se<z;x>). 

Now  from  (***)  and  the  preceding  observations?  we 
can  conclude 

P  {begin  new  x;  Q  end}R. 

QED 


5.  tf Richer”  domains  of  discourse 

Our  example  language  was  defined  using  a  set  of  domains 
chosen  to  mirror  accurately  the  assertions  that  could  be 
made  about  programs.  In  the  sense  that  in  both  definitions 
the  domains  of  discourse  were  identical?  the  definitions 
given  above  can  be  seen  as  defining  the  same  language. 
However?  the  domains  of  discourse  used  in  the  previous 
definitions  are  obviously  not  adequate  for  the  definition  of 
many  of  the  constructs  found  in  more  complex  languages.  An 
important  aspect  of  the  use  of  mathematical  definitions  as 
complements  to  axiomatic  definitions  is  the  ready 
availability  of  a  framework  to  study  the  validity  of  the 
rules  of  inference  in  the  context  of  more  complex  but 
related  languages. 

As  an  example?  we  consider  a  language  for  which  the 
complete  semantics  require  a  more  refined  notion  of 
environment  and  store?  but  with  some  constructs  identical  in 
syntax  to  that  of  the  language  given  above.  In  this  related 
language  we: 
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1.  allow  the  notion  of  an  identifier  referencing  a 
location  and  of  a  location  containing  a  value,  and 

2.  require  the  store  to  have  a  component  containing  the 
next  unused  location. 

In  other  words,  the  new  domain  of  discourse  includes  the 
following: 

Env®  -  lfi->Dvai®  environments 

Dval®  =  Loc  «■  ...  denotable  values 

Loc  locations 

Store  =  [Loc->Value]  x  Loc  machine  stores 

Value  storable  values 

Cont®  -  Store->Store  continuations 

and  statements  in  our  new  language  are  defined  relative  to 

this  new  set  of  domains.  The  new  meaning  functions  have 

functionalities: 

Me® : Exp->[ Env9 ->[  St ore->Eval ] ] 

Ms8 : Stmt->[Env® ->[Cont9->[ Store->Store  ]]]. 

We  first  give  the  meaning  of  our  constructs  in  terms  of  the 

new  semantic  domains  and  then  discuss  the  conditions  under 

which  our  previously  given  axioms  are  valid  with  respect  to 

the  new  model: 

Ms®  {begin  stmt  end}  =  Ms®  {stmt} 

Ms® {id:-exp}  = 

(Sny*  e: Cont®  c; Store  s) Store: 
let  v  =  Me®  {exp}  {e;  s) 
in 

if  v=t  then  t 
else  if  v=b  then  b 
else 

c(s[e{id}/v  in  Value]} 

Ms®  {if  exp  then  stmtl  else  stmt2  end}  = 

CEnv ®  e;Cont®  c ; Store  s) Store: 
let~b  =  Me®  {exp}  ( e ;  s)  |Bool 
in 

(b->Ms8  {stmt  1}  ,  Ms®{stmt2}5  (e;  c;  s) 
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Ms*{stmt1;  stsnt2}  = 

(Env®  e; Cent®  c; Store  s) Store : 

Ms*  {stall }  (e;  Ms*  {stmt2}  (e;  c)  ;  s) 

Ms®  {while  exp  do  stmt  end}  = 

rec  (Env®  e;Cont*  c; Store  s) Store : 
let  b  =  Me*  {exp}  (e;  s) |Bool 

o 

in 

(b->Ms*  {stmt}  (e;  Ms® {while  exp  do  stmt  end}  {e;  c)  ) ,  c )  (s) 

Ms* {begin  new  id;  stmt  end}  = 

(Env*  e;Cont *  c ; Store  s) Store : 

Ms* {begin  stmt  end} (e[ id/s<2> ];  c;  (s<1>[ s<2>/u  ], New ( s<2>) 
where  New ; Loc->Loc  is  any  1 -to-1  mapping. 

What  we  wish  to  do  is  to  establish  conditions  under 
which  the  new  definitions  satisfy  the  old  axioms. 
Obviously,  if  for  every  exp€Exp, 

Me  {exp}  (e;  s)  =  Me®  {exp}  (e*;  s®), 
then  for  any  propositional  expression  P, 

P (e ;  s)  <=>  P  (e® ;  s*) . 

Thus  to  establish  conditions  under  which  the  new  definitions 
satisfy  the  axioms,  we; 

1.  establish  a  relation  r  between  elements  of 

[Env  x  State]  and  [Env®  x  Store] 
such  that 

Me{exp}(e;  s)  =  Me*{exp}(es;  s* ) 
for  every  exp€Exp  iff 
r:  (e,s)  h->  (e®  ,s®)  . 

Then  we  have 

P  (e;  s)  <=>  P  (e« ;  s*)  iff 
r:  (e,  s)  (e«  ,s*)  . 

2.  give  sufficient  conditions  for  r  to  be  preserved  by 
execution  of  a  statement.  Then  for  all  executions 


111 


satisfying  the  given  conditions,  the  previously 
given  axioms  will  remain  valid. 


Definition :  Let  r  be  a  relation  in 

[Env  x  State] — XCEnv*  x  Store] 
such  that 

r  :  (e,  s)  i-»(e',s')  iff  ¥ieid, 

1.  e  (i)  =  b  and  e'  (i)  =  b  or 

2.  e(i)  =  t  and  e®  (i)  *  t  or 

3.  e®(i):Loc  =  true  and  e  (i)  =  s*<1> (e®  (i) ) . 


Lemma :  Me{exp}(e;  s)  =  Me*  {exp}  (e®  ;  s®)  for  ail  exp€Exp  iff 

r s  (e, s)  (e®  ,s ' )  . 


Proof :  By  structural  induction  on  exp. 


Lemma:  P(e;  s)  <=>  P(e®;  s*)  for  all  P  iff 

r :  (e, s)  (e*  ,s* )  . 


Proof:  By  structural  induction  on  P. 


Theorem:  Let  LHS(stmt)  be  the  set  of  free  (i.e.,  not 

bound  to  any  internal  declaration)  variables  found 
on  the  left-hand  side  of  the  assignment  statements 
of  stmt.  If  for  some  e*€Env', 
e*  (x)  :Loc  =>  e®  (x)#e*  (y) 
for  each  x,  y  in  LHS(stmt),  then  if 
r:{e,s)  t-^(e®,s*),  then 
Ms  {stmt}  (e;  c;  s)  =  c  (si)  iff 
Ms®  {stmt}  (e* ;  c®;  s*)  =  c*(s1®)  and 
r  :  (e,  si)  r»(e*  ,  si®)  . 


Proof :  By  structural  induction  on  stmt. 


Putting  together  the  preceding  lemmas  and  theorem,  we 
see  that  it  is  sufficient  for  the  environment  to  map 
distinct  identifiers  to  distinct  locations  to  preserve  the 
validity  of  the  axioms  with  respect  to  our  new  definitions. 
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That  this  is  not  a  necessary  condition  can  be  seen  from  the 
following  sequence: 

x:  =  1 ; 
y:  =  1 

If  x  and  y  were  mapped  to  the  same  location  by  an 
environment*  the  resulting  store  and  environment  would 
produce  the  same  values  for  x  and  y  as  would  one  in  which 
both  identifiers  were  mapped  to  distinct  locations. 

Also,  although  the  rules  of  inference  given  above  may 
not  hold  for  arbitrary  environments  and  stores*  it  may  still 
be  true  that  they  hold  for  all  environments  and  stores 
produced  during  the  execution  of  any  syntactically  valid 
program.  If  it  can  be  shown  that  from  a  particular  initial 
environment  and  store*  no  environment  can  be  formed  sapping 
two  or  more  identifiers  to  the  same  location*  then  the 
theorem  given  above  holds  for  all  statements  contained  in 
such  programs.  Then*  of  course*  the  rules  of  inference 
given  in  section  3  would  be  valid  for  all  such  programs 
without  exception. 

This  approach  to  proving  definitions  consistent  has  also 
been  applied  by  the  author  to  a  number  of  other  common 
language  constructs*  including  PASCAL  procedures.  The 
difference  in  expressive  power  of  the  two  sets  of  domains 
used  above  appears  in  two  aspects  of  the  meaning  of 
procedures.  First*  the  notion  of  "call  by  reference89  in  the 
environment/store  model  must  be  defined  in  the  program  state 
model  using  a  form  of  definition  similar  to  "call  by 

.'V 
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value/result. M 

Second?  and  most 

important. 

is 

the 

difference  in 

handling  of  non-local 

variables. 

In 

the 

environment/store  model?  the  usual  technique  of  forming  a 
« program  closure”  binding  the  environment  at  the  time  of 
declaration  also  binds  identifiers  to  locations?  giving  the 
semantics  common  to  Algol  and  its  descendents.  However?  the 
program  state  model  does  not  allow  the  possibility  of  such  a 
semantics?  since  program  variables  can  not  be  bound  at  the 
time  of  declaration.  This  produces  a  semantics  with  the 
dynamic  scope  properties  of  a  language  like  SN0B0L4.  This 
second  treatment  of  non-local  variables  can  be  used? 
however?  to  give  a  mathematical  semantics  satisfying  the 
rule  of  inference  previously  given  for  PASCAL  procedures.  A 
more  detailed  discussion  of  these  points  will  appear  in  the 
author «s  forthcoming  Ph.D.  thesis. 

6 .  Conclusion 

The  motivation  behind  complementary  definitions  of 
programming  languages  is  to  provide  specialized  definitions 
to  meet  the  needs  of  particular  audiences.  Certainly  the 
axiomatic  approach  to  semantics  has  been  shown  to  be  highly 
useful  in  the  development  of  formal  proofs  of  program 
properties.  Yet?  as  was  noted  above?  it  seems  that  the 
limitations  of  the  axiomatic  approach  make  it  unsuitable  as 
the  only  definition  of  the  semantics  of  a  language. 
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The  mathematical  approach  to  semantics  appears  to  be  a 
good  complement  to  the  axiomatic  approach*  The  notion  of 
computation  that  is  implicit  in  axiomatic  definitions  is 
made  explicit  using  mathematical  semantics*  thus  providing  a 
more  suitable  implementation  guide.  Also*  the  mathematical 
approach  is  not  limited  to  a  restrictive  domain  of 
discourse*  as  is  the  proof  system  given  in  Section  3.2. 
And*  finally*  the  existence  of  an  underlying  theory  of 
computation  provides  a  useful  framework  to  study  the 
questions  of  consistency  of  complementary  definitions. 

From  the  point  of  view  of  reliable  software*  two  aspects 
of  complementary  definitions  are  important.  The  development 
of  a  mathematical  definition  and  proof  of  the  consistency  of 
mathematical  and  axiomatic  definitions  provide  an  important 
check  on  the  validity  of  the  axiomatic  definition  as  a 
proper  abstraction  of  the  properties  of  a  language 
construct.  Moreover*  the  mathematical  definition  provides  a 
more  useful  model  from  which  to  develop  an  implementation. 
This  makes  it  more  likely  that  the  properties  formally 
proven  about  a  program  will  be  true  for  actual  executions  of 
the  program.  And*  an  increased  likelihood  of  a  correct 
implementation  makes  the  effort  of  developing  formal  proofs 
of  program  properties  easier  to  justify. 

Another  important  aspect  of  complementary  definitions  is 
the  process  of  their  development.  As  the  previous  example 
illustrates*  the  question  of  what  a  construct  in  a  language 
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"really"  means  is  made  unusually  clear  by  the  requirement  to 
give  and  prove  consistent  multiple  definitions  of  a  language 
construct.  And  certainly,  a  better  understanding  of  the 
programming  languages  we  use  can  not  help  but  improve  our 
ability  to  produce  reliable  programs. 
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Appendix 


The  relation  between  our  notation  for  function 
definition  and  lambda  expressions  is  the  following: 

1.  for  untyped  lambda  expressions 

x.body  =  (x)  :  body 

2.  for  typed  lambda  expressions 

xCD.body  =  (D  x) : body 

3.  for  a  sequence  (x1,...,xn) 

(xl , . . . f xn) . body  =  (xl,  •••#  xn) :body 

4.  for  ‘'Curried”  functions 

xl.  x2.  ...  xn. body  =  (x1;x2;  ...;  xn) :body 

5.  if  f : D->D • ,  its  definition  will  be  written  as 

f  =  (D  x) D* :  body. 

6.  also  if  f  is  of  type  D1->[D2->D],  then 

f  (dl)  (d2) 

will  be  written  f(d1;  d2)  . 

Additionally,  the  following  notational  conventions  will 
be  observed: 

1.  If  i  is  a  member  of  a  domain  of  type 

Dl  xD2x...  xDn 

then  m<i>  is  a  member  of  Di  and  is  the  i-th 
component  of  m. 

2.  The  construction 

let  D  x  =  a  in  body 
is  defined  as 
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( (D  x)  :  body)  (a) 


3.  The  application  of  functions  to  elements  of 
syntactic  domains  will  be  written  using  {  and  } 
rather  than  (  and  ) •  Also,  arbitrary  elements  of 

•l  &  ... 

syntactic  domains  will  be  denoted  using  the  name  of 
the  domain  beginning  with  a  lower  case,  rather  than 
an  upper  case,  letter. 

4.  Recursive  definitions  of  domain  elements  will  be 
written  as 

f  =  rec  F  (f ) 

and  will  be  understood  to  denote  the  least  fixed 
point  of  F  in  all  cases. 

Some  important  functions  which  will  be  used  frequently 
in  the  definitions  are: 

1.  If  X  is  a  domain  of  type  D->D®,  then 

X[v  /  e]:D->D« 

is  defined  as 

X[ v/e  ]  =  (D  d)D»:  if  d=v  then  e  else  X(d). 

This  can  be  read  as  "change  the  v  component  of  X  to 
be  e.” 

2.  The  conditional 

b  ->  v 1 ,  v2 

is  defined  for  the  lattice 
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Bool  = 

t 

I 

I 

r— —1 


true  false 

1  i 

3  I 

8- - ----J 

s 

5 

b 

(a  part  of  Value)  ,  as  follows: 

_ b _ 

t  |  t 

true  S  v  1 
false  l  v2 

bib 

This  is  the  ”doubly  strict”  extension  of 

if  b  then  vl  else  v2 

(a  function  is  doubly  strict  if  it  maps  b  to  b  and  t 
to  t) .  Note  that 

b  ->  vl,  v2 

is  a  continuous  function  on  the  lattice  Bool  for 
continuous  vl  and  v2,  unlike 

if  b  then  vl  else  v2 

which  is  defined  for  the  set  {true,  false}  and  for 
which  continuity  can  not  be  automatically 
guaranteed. 

3.  If  Y  is  a  domain  of  type 

Y  =  .  .  .  *  X  *  . .  . 

then  the  functions  of  inspection ,  projection,  and 
injection  are  defined  as: 
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a.  For 

any  v€Y a  the  inspection  of  X  for  v.  written 

y  sX* 

is  defined  as: 

y :  X  = 

=  true*  if  y  corresponds  to  a  member  of  X*  or 
false*  if  y  does  not  correspond  to  any  x€X« 

b.  For 

any  y  €  Y,  the  projection  of  y  into  X» 

written  yJX  is  defined  as: 
y  j  X  =  x  if  y  corresponds  to  x0X*  or 


b  if  y  does  not  correspond  to  any  x€X« 

c.  For 

any  x€X,  the  inlection  of  x  into  Y„  written 

x  in 

Y  is  defined  as: 

x  in  Y  =  y  where  y€Y  corresponds  to  x. 

All  of  these  functions  are  doubly  strict  in  their 
first  argument* 
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